Last week I received a take-home assignment from a company calling itself a real estate technology firm. The email was well-formatted. The instructions were plausible. The package was a zipped Node.js project with a README that asked me to implement a data ingestion feature and return the result within forty-eight hours. Standard stuff. I've done thirty of these in the past year.

I did not run it.

What I found instead, after twenty minutes of static analysis, was a three-stage infostealer with a persistent socket backdoor, a browser credential exfiltration loop, and a recursive filesystem sweeper that specifically prioritizes ~/development, ~/Development, ~/Documents, and ~/Desktop — in that order — before crawling the rest of your home directory for anything matching the words "wallet," "private_key," "seed," "api_key," "token," ".env," or "password." The payload was 3.8 MB of obfuscated JavaScript. The legitimate-looking feature request was the delivery mechanism. The take-home was the pretext.

This post is the deobfuscation report, the anatomy lesson, and the checklist — written for the developer who has run twelve take-homes this year and never once audited what was in the package before executing npm install && npm start.

1. The shape of the attack

Before the technical details, the shape matters because the shape is what you need to recognize next time.

The attacker's goal is to get you to run node on their code. That's it. Everything else — the professional email, the Calendly invite for a follow-up call, the plausible-sounding feature description — exists to build enough trust that you type npm install && npm run dev without opening the package.json first. Once that command runs, the payload is executing. You will not see a terminal flash or a suspicious popup. The infostealer spawns three detached child processes and immediately returns control to the "real" application. The feature works. The tests pass. You submit your assignment. The data leaves in the background.

The variant I analyzed was embedded in a build script called from the project's postinstall hook — the hook npm runs automatically after npm install completes, before you've even read the README. This is not a novel technique. Malicious postinstall hooks have been a known attack surface since at least 2018. The novel part is the sophistication of what ran inside the hook and the deliberateness with which it targeted developers specifically: people who by definition have API keys, database credentials, private repositories, and crypto wallets, all sitting in a well-organized ~/development directory, all matching the payload's sensitive keyword list.

2. Three workers, three lock files, one temp directory

The payload's architecture is clean enough to admire in a grim way. On execution it spawns three detached Node.js processes by piping script strings to node - via child_process.spawn. Each worker is passed as a string of code written to the child's stdin — meaning the workers never exist as files on disk you might notice in a directory listing. Each worker writes a lock file to os.tmpdir() (pid.6.1.lock, pid.6.2.lock, pid.6.3.lock) to prevent duplicate instances. If a lock file already exists with a running PID, the payload kills the old process and spawns a fresh one. If the machine restarts and the lock files go stale, the next npm install on any project carrying this hook resurrects all three workers.

The three workers communicate with a command-and-control server at 144.172.117.220 on three different ports:

• Port 8085 — browser credential and wallet file upload
• Port 8086 — sensitive filesystem file upload
• Port 8087 — real-time socket backdoor, beacon, and clipboard stream

When I captured the response headers, the server returned a Vercel edge response with a valid strict-transport-security header and a live x-vercel-id. The C2 was alive at the time of analysis. The upload endpoints were accepting connections.

3. Worker one: your browser is an unlocked credential store

The first worker targets Chromium-family browsers — Chrome, Brave, Edge, Opera, and their variants — across Windows, macOS, Linux, and WSL. It knows where each browser stores its profile data on each platform. It reads the Login Data SQLite database that every Chromium browser uses to store saved passwords, then it attempts to decrypt them.

The decryption flow is the part that surprises people who assume "saved passwords are encrypted." They are, but the encryption key is also stored locally, protected by the operating system's credential API. On macOS, the payload calls security find-generic-password -w -a 'Chrome' -s 'Chrome Safe Storage' to extract the Keychain key, then runs the PBKDF2 derivation that Chrome uses internally to produce the AES key, then decrypts the stored credentials. On Windows it uses PowerShell to call the DPAPI. On Linux it calls secret-tool. These are the same APIs your password manager's native app uses. The browser's designers never contemplated a script running in your terminal asking the OS for the key and the ciphertext in the same process.

The result is a plaintext dump of URLs, usernames, and passwords that gets uploaded to port 8085 every thirty seconds for up to ten cycles — five minutes of active exfiltration even if you close the terminal immediately after noticing something wrong.

Beyond passwords, the worker collects:

• Session cookies from all profiles (allowing account takeover without the password)
• Web Data (autofill, stored form values, potentially credit card numbers)
• login.keychain-db on macOS
• The extension storage directories for approximately fifteen browser crypto wallet extensions — MetaMask, Phantom, Exodus, Coinbase Wallet, Brave Wallet, Rabby, Coin98, and others

The wallet extension data is the prize for a certain class of attacker. Browser wallets store encrypted vault data locally. The encryption password is the user's wallet password. If that password is weak, the vault is offline-crackable. If the user has a hardware wallet passphrase set, the seed phrase is still in the extension's storage at rest. The payload does not attempt to crack the vault — it just uploads it and lets the C2 operator handle decryption offline, with GPU time they control.

4. Worker two knows where developers keep their secrets

The second worker is a recursive filesystem sweeper. It starts with a five-minute delay — enough time for the developer to submit the assignment and stop watching their terminal — then begins scanning.

The priority directory list is the thing I found most revealing about the attacker's intent:

~/Desktop
~/Documents
~/Downloads
~/Library/CloudStorage
~/Development
~/development
~/Code
~/code
~/Projects
~/projects
~/Source
~/source
~/OneDrive
~/Google Drive

This is not a generic consumer infostealer. A generic consumer infostealer targets Documents and Downloads and stops there. This one explicitly lists ~/development, ~/Development, ~/Code, ~/Projects, ~/Source — the directories that exist on developer machines and essentially nowhere else. The attacker knows their target demographic. They know developers keep projects there. They know those projects have .env files. They know those .env files have the keys to your cloud infrastructure, your payment processor, your database, and your AI API accounts.

After the priority directories, the worker scans the full home directory with a keyword filter. Any file whose path contains one of these terms gets uploaded if it is under 5 MB:

• Credentials: password, passwd, token, api_key, secret, credential, auth
• Keys and certs: id_rsa, id_ed25519, .pem, .p12, .pfx, .jks, keystore
• Crypto: wallet, seed, mnemonic, private_key, bitcoin, ethereum, metamask, phantom, ledger, trezor
• Config files: .env, .yml, .yaml, .toml, .conf, .cfg, .ini, .properties
• Documents: .pdf, .docx, .md, .txt, .csv, .xls, .xlsx
• Databases: .db, .sqlite, .sqlite3, .sql
• Source code: .js, .ts, .json, .jsx, .tsx, .xml
• Images: .png, .jpg, .jpeg

That last category — images — is there for screenshots. Most developers have screenshots of dashboards, infrastructure diagrams, API key configuration pages, terminal sessions. Screenshots are a surprisingly rich data source for credential recovery.

The exclusion list is equally telling. The payload explicitly skips node_modules, .git, venv, dist, build, .next, .cache, vendor, and a hundred other paths that would generate noise without yielding secrets. This is tuned. Whoever wrote it understood the shape of a developer's filesystem well enough to write a precise filter. The inclusion and exclusion lists together constitute a detailed model of what a working developer's machine looks like.

5. Worker three: the clipboard is a live credential stream

The third worker maintains a persistent socket.io connection to the C2 server on port 8087. On connect, it immediately beacons your hostname, OS version, and username. It then does two things in parallel.

The first is an environment file hunt: after five minutes, it searches the entire filesystem for any file matching \.env* and uploads everything it finds to port 8085. Not just .env — .env.local, .env.production, .env.staging, .env.test, .env.backup. Every variant. Every project.

The second is clipboard surveillance. The worker polls your clipboard approximately every second using platform-native tools — pbpaste on macOS, PowerShell's [System.Windows.Forms.Clipboard]::GetText() on Windows, xclip or xsel on Linux. Any new non-empty clipboard content is sent as a log event to /api/log on the C2 server.

Think about what passes through your clipboard on a working day. API keys copied from a dashboard to paste into a .env file. Database connection strings. SSH passwords. JWT tokens copied from a browser devtools console to test an endpoint. Wallet addresses. Seed phrases (if you are the kind of person who ever copies a seed phrase — you should not be, but people do). Every one of those clipboard snapshots, timestamped and tagged with your hostname and username, streams to the C2 in real time for as long as the worker is running.

The socket channel also accepts remote commands from the C2 operator. Command code 102 returns a directory listing. Command code 107 reads a specific file and exfiltrates it. Command code 108 bulk-uploads every file in a specified folder under 25 MB. This is a full remote shell in everything but name.

6. The evasion stack

The payload earned my grudging respect in one sense: the evasion design is layered, and each layer targets a different detection mechanism.

Obfuscation. The original file was 3.8 MB of obfuscated JavaScript — string tables, integer-key lookups, junk branch logic, anti-debug heartbeats that call setInterval every two seconds. Static analysis requires a dedicated deobfuscation pass before the behavior is readable. A developer who opens the file and sees 3.8 MB of compressed variable names closes it and moves on.

No files on disk. The workers are never written to disk as named files. They are strings piped to node - via stdin. ps aux shows a node process with no arguments except the interpreter. There is nothing in the filesystem to find.

Detached processes. spawn(..., { detached: true }) causes the workers to be reparented to PID 1 (or the Windows equivalent) on Unix systems. The parent process exits normally. The terminal returns. The workers keep running.

Swallowed exceptions. process.on("uncaughtException", () => {}) and process.on("unhandledRejection", () => {}) suppress all unhandled errors globally. The workers will not crash on malformed responses, revoked tokens, or unexpected filesystem layouts. They will silently continue.

Runtime dependency installation. If socket.io-client, axios, sql.js, or form-data are not installed in the victim's global npm environment, the payload installs them with npm install --no-save and re-requires them. It adapts to the victim's environment rather than assuming it.

Anti-debug noise. A setInterval every two seconds triggers a function that creates Function().constructor("return this")() — a construct that evaluates arbitrary code and makes tracing the execution graph noticeably harder. Most analysts give up before the behavior tree is fully mapped.

The combination of these techniques means that standard "run it in a VM and watch what happens" dynamic analysis still exposes the behavior — the network connections to port 8085/8086/8087 are clearly visible in a packet capture — but defeats casual inspection and makes it through most automated static analysis passes that look only for known bad strings.

7. What to do before you run any take-home assignment

I want to be precise here because "use a VM" is the advice everyone gives and almost nobody follows. VMs are slow to set up, inconvenient for multi-hour assignments, and give you a false sense of safety if you copy your real SSH keys or API credentials into them (which people do). Here is what actually fits into a realistic pre-run check that takes under ten minutes.

Read package.json first, completely. The scripts field is the attack surface. postinstall, preinstall, prepare — these run automatically. If any of these scripts call a file you have not read, read the file. If any of them call node scripts/something.js and scripts/something.js is 3.8 MB of minified code, that is your signal. Legitimate take-home assignments do not need 3.8 MB of compressed JavaScript in their build pipeline.

Check dependencies and devDependencies against the stated scope. An assignment that asks you to build a REST endpoint does not need socket.io-client, sql.js, or form-data unless those packages are relevant to the feature. Unexpected dependencies in a small project warrant investigation.

Grep the non-minified files for network calls. grep -r "http\|https\|socket\|fetch\|axios\|got\|request" --include="*.js" --include="*.ts" . on the unminified source. Legitimate take-homes do not phone home. If you see an IP address in a source file that is not localhost or a well-known API, stop.

Run npm install --ignore-scripts first. This flag tells npm to skip all lifecycle scripts (preinstall, postinstall, prepare, etc.) and just install the packages. Inspect everything, then decide whether to allow scripts.

Block outbound network for the duration. On macOS, pfctl can block outbound connections from a specific process. On Linux, firejail --net=none node . runs the process with no network access. If the application needs network access that is legitimate (calling the assignment's specified API), you will know about it from the README. Unexpected network connections during the interview task are not a feature.

None of this is foolproof. A sufficiently sophisticated payload will hide its indicators. But the category of attack I analyzed — interview-targeted Node.js infostealers — is not sophisticated in its delivery. It is sophisticated in its payload. The delivery relies on the developer's habit of trusting the interview context enough to skip the audit.

8. The upload infrastructure tells you something about the operator

The C2 infrastructure deserves a paragraph. The three upload endpoints are plain HTTP at 144.172.117.220, a cloud-hosted IP with no domain name. Port 8087 (the socket and beacon channel) is fronted through Vercel — the response headers include a x-vercel-id with an iad1 region marker, meaning the operator is proxying the WebSocket channel through Vercel's edge network for a different IP profile on port 443.

Each upload includes a validation HMAC computed with the secret SuperStr0ngSecret@)@^. Every file upload carries the victim's hostname, the file path (URL-encoded), a Unix timestamp, and the campaign marker userKey=609, t=6. This is a multi-tenant C2 — t=6 is the tenant or campaign identifier, and userKey=609 is likely a unique victim identifier assigned at delivery time. The operator can correlate all uploads from a single victim across all three workers using these markers.

The retry logic and validation scheme suggest a mature operation rather than a one-off experiment. A first-time attacker does not write exponential backoff logic with per-file retry counts and HMAC-validated uploads. Somebody has been running this for a while.

9. The incident response question you should answer first

If you are reading this after running an untrusted package, the first question is not "how do I remove it." The first question is "what was on this machine."

That question is harder and more important. If your ~/development directory was scanned, every .env file in every project was potentially uploaded. Every API key you have ever configured locally is now at risk. Every browser-saved password on this machine is potentially in the attacker's hands. Every piece of text you have copied to your clipboard in the time since the payload executed is logged.

The remediation checklist is:

1. Rotate every API key and secret in every project, immediately, before doing anything else. Prioritize cloud credentials (AWS, GCP, Azure), payment processor keys (Stripe, Braintree), and AI API keys (Anthropic, OpenAI). A rotated key on a compromised project is useless to the attacker; an unrotated key is a live credential even after you've wiped the machine.
2. Log out of every active session — GitHub, email, banking, cloud consoles, anything you access from this machine. Revoke OAuth tokens where possible. The session cookies from your browser profiles may have been exfiltrated.
3. Revoke and regenerate SSH keys. Push the new public key to every service and host. Treat every existing id_rsa, id_ed25519, or .pem file as compromised.
4. If you have any crypto wallet funds accessible from this machine, move them to a fresh wallet generated on an air-gapped device. Treat any seed phrase or private key that has ever been on this machine as known to the attacker, even if you stored it "securely."
5. Check for running workers: ps aux | grep node. Look for pid.6.*.lock files in your temp directory ($TMPDIR on macOS, /tmp on Linux). Kill any lingering processes.
6. Rotate any password or secret you may have typed or copied to clipboard during the infection window.

Step one takes longer than everything else. Do it first anyway.

10. The cultural problem that makes this attack work

There is a structural problem with the technical interview pipeline that this attack exploits, and naming it matters because fixing the checklist alone will not fix the underlying vulnerability.

Developers are conditioned to treat the interview context as a trust boundary. The hiring manager emailed you. They found you on LinkedIn. The assignment is from a real company (or appears to be). The psychological contract of "I am being evaluated so I should perform, not investigate" suppresses exactly the skepticism that would catch this attack. Nobody audits code they are about to be graded on the same way they would audit a random package. The social framing of the take-home is the exploit.

Attackers understand this. The real estate company framing in the sample I analyzed is plausible and unremarkable — real estate tech companies run take-home assignments constantly, the domain is boring enough not to raise questions, and the feature request (data ingestion pipeline) is exactly the kind of thing you would expect. Nothing in the email or the README flags as suspicious. The payload hides in a build script that runs before you read a single line of the application code.

The fix has to be a habit, not just a checklist. Make npm install --ignore-scripts your default for every unfamiliar project. Make reading package.json before running anything a reflex. Take the ten minutes to check network calls in the source before you type npm start. These are habits that cost you very little on legitimate assignments — legitimate assignments do not have malicious postinstall hooks — and that will catch the attack on the one in fifty assignments where the package is not what it claims to be.

The inconvenient truth is that the developers most at risk are the ones who are most active in the job market: recent grads doing thirty take-homes a year, experienced engineers exploring new roles, contractors evaluating client projects. These are also the people with the most API keys, the most cloud credentials, and the most active side projects sitting in a well-organized ~/development directory. The attack selects for exactly this profile, which is why the priority directory list says ~/development before it says ~/Documents.

You are the target because you are a developer. That knowledge should be inconvenient enough to make you open package.json before you type npm install.

The payload I analyzed has been reported to the hosting provider and to GitHub's security team. If you receive a take-home from a company you do not recognize with a Node.js project that includes a build script you cannot read, you are welcome to run the same grep queries I described in section seven. They take four minutes. They will not slow down your legitimate job search. They will, eventually, save you the experience of rotating fifty API keys at midnight while reading through what a three-stage infostealer took from your machine.