Is That Take-Home Assignment Malware? How to Check

Most take-home assignments are exactly what they look like. A small share are malware delivery, aimed specifically at developers, and they are convincing enough that antivirus scanners have missed the archives entirely. The attack does not need you to click a suspicious link. It needs you to do the ordinary thing a candidate does with a coding test: clone the repository, install the dependencies, and run it.

This article is about the risk pointed at you during a technical hiring process, rather than the monitoring pointed at you during an assessment. It covers what the current campaigns actually do, which signals separate a real take-home from a delivery vehicle, how to run an unfamiliar assignment without exposing your machine, and what to do if you already ran one.

The campaign that makes this a live question

Microsoft's threat intelligence team describes Contagious Interview as "a sophisticated social engineering operation active since at least December 2022" in which attackers impersonate recruiters at cryptocurrency and AI companies and direct candidates to clone and execute packages hosted on GitHub, GitLab, or Bitbucket during fake technical interviews (Microsoft Security Blog, March 11, 2026). Microsoft names several payload families in the campaign, including OtterCookie, Invisible Ferret, and FlexibleFerret, and reports that they harvest API tokens, cloud credentials, cryptocurrency wallets, and source code, with keylogging and clipboard monitoring on top.

Elastic Security Labs documented a specific instance in detail. A supposed recruiter posted job opportunities in Elastic's own community Slack workspace, then sent interested candidates trojanized repositories dressed up as e-commerce projects. The candidate's instruction was simply to run the project — npm run dev or npm start — to demonstrate competence. The payload was split into base64 chunks hidden in HTML comments inside SVG country-flag files, reassembled at server startup by a plausible-looking file named serverValidation.js, and executed. Elastic notes that the distributed archives had zero antivirus detections at the time of analysis (Elastic Security Labs, July 18, 2026).

What the payload took, per Elastic's analysis, is the part worth internalizing: browser login data and autofill entries from Chrome, Edge, Brave, and Firefox across Windows, macOS, and Linux; a recursive file sweep for patterns including *.env, *.pem, and *.ssh; a persistent remote-access channel; and a clipboard stealer polling every 500 milliseconds. A single npm start in your normal user session is enough to hand over a working set of your credentials.

The delivery surface is broader than repositories. In June 2025, researchers found 35 malicious npm packages published from 24 accounts with more than 4,000 combined downloads, distributed through assignments hosted on Bitbucket and disguised as legitimate tests. That report also records the behavioral tell most worth remembering: attackers "pressure candidates to run the code outside containerized environments while screen-sharing" (BleepingComputer, June 25, 2025).

A separate variant skips the code entirely. Sekoia documented a fake "Willo" video-interview site that displays a camera-driver error and instructs the candidate to fix it by opening Command Prompt on Windows, or Terminal on macOS, and running a curl command that fetches and executes a script. Sekoia attributed the campaign to the Lazarus Group and observed it aimed largely at business development and asset management roles rather than engineers (The Hacker News, April 3, 2025). If an interview page ever asks you to paste a command into a terminal to enable your webcam, that is not how webcams work.

Where the code actually runs

Three execution points cover nearly all of these cases, and each one is a step a candidate takes voluntarily.

Dependency installation. npm install, pip install, and their equivalents run package-defined lifecycle scripts. Reading the application source tells you nothing about what a postinstall hook in a transitive dependency does.

Running the project. npm run dev starts the server, and the server's startup path is a normal place to hide an initializer that looks like validation, telemetry, or config loading.

Opening the folder in an editor. VS Code's Workspace Trust exists precisely for this. Microsoft's write-up notes that when a victim opens the downloaded package and grants trust, the editor executes the repository's task configuration. VS Code's own documentation is blunt about why: task definitions live in the committed .vscode folder and are "shared to every user of that repo," so a malicious task "could be unknowingly run by anyone who cloned that repository" (VS Code Workspace Trust documentation). Restricted Mode disables tasks, terminals, debugging, and workspace settings until you say otherwise.

Signals that mean very little on their own

Getting this wrong in the paranoid direction costs you real interviews, so it is worth being precise about what is not evidence.

A private GitHub repository is normal. A four-hour take-home is normal. Being asked to clone and run the project locally is normal — that is what a take-home is. A recruiter contacting you cold on LinkedIn is normal. A startup with a thin web presence is normal, because most startups have one. None of these, alone or stacked, tells you much.

The useful signals are about pressure and mechanism, not about polish.

Signals worth stopping for

• The task requires running before reading. A legitimate assignment gives you a spec and asks you to write code. A delivery vehicle gives you a large existing codebase and asks you to run it and report what you see.
• Someone objects to your sandbox. A real engineering team does not care whether you work inside a container or a VM. Explicit pressure to run outside a container, particularly on a live screen share, is the single strongest documented tell.
• Any instruction to paste a shell command to fix a device, driver, or browser problem. Interview platforms fix compatibility problems by telling you to use a different browser, not by having you pipe a remote script into your shell.
• The recruiting flow lives entirely in Telegram, Discord, or a Slack community, with no email from a company domain and no listing on the company's own careers page.
• The role is crypto- or AI-adjacent and the pay band is conspicuously high for the described scope. These campaigns concentrate there.
• Repository archives arrive as direct downloads — a .zip or .rar sent over chat rather than a link to a repository you can browse and inspect first.

Verify the employer through a channel the recruiter did not give you. Find the company's careers page yourself and confirm the role exists; find the recruiter on the company's site rather than trusting the profile that contacted you. The same instinct applies to any hiring step that asks for something valuable — the reasoning in this candidate's guide to interview identity verification transfers directly, since a fraudulent ID request and a fraudulent code request are the same trick pointed at different assets.

How to run an unfamiliar take-home safely

Microsoft's own recommendation is the short version: "use a dedicated, isolated environment for coding tests and take-home assignments." In practice that means a few concrete habits.

Isolate before you install. A disposable VM or a container is the boundary that matters, because it is the one that survives being wrong about a repository. Run the assignment in a fresh VM, a dev container, or a cloud workspace you can destroy. Do not use the machine that holds your SSH keys, your cloud CLI sessions, and your browser profile.

Read before you run, in that order. Open the folder in Restricted Mode. Read package.json for preinstall, postinstall, and prepare scripts. Skim the lockfile for dependencies you do not recognize. Look at what the server does on startup. This takes ten minutes and defeats the mechanism described above, which depends on execution preceding inspection.

Give the environment nothing worth stealing. No signed-in browser profile, no .env from another project, no SSH agent forwarding, no cloud credentials, no wallet extensions. If the assignment needs an API key, generate a throwaway one scoped to that project.

Treat obfuscation as a decision point, not a puzzle. Long base64 strings, eval() on assembled fragments, minified code in a repository that ships no build step, or payload-shaped data inside image and asset files are all reasons to stop and ask the employer directly. Do not try to decode and run it to satisfy your curiosity.

For assignments where the concern is policy rather than security — what tooling you are permitted to use and what the employer expects you to disclose — the 2026 rules for AI use in take-home assignments covers that separately.

If you already ran one

Assume credential theft rather than file damage, and move in that order. Disconnect the machine from the network. From a different device, rotate the credentials that were reachable: browser-saved passwords, cloud provider keys, personal access tokens for GitHub and npm, SSH keys, and any session that can be revoked centrally. Enable or re-verify multi-factor authentication on your email and code hosting accounts first, since those are the recovery paths for everything else. Check for authorized OAuth applications and SSH keys you did not add. If a cryptocurrency wallet was present in that browser profile, treat its seed phrase as exposed.

Then rebuild rather than clean. These payloads are modular and designed for persistence, and a scan that finds nothing proves less than usual given the zero-detection archives above. If the machine had employer access, tell your security team — same day, and before you finish reading this list.

The same vetting applies to interview software you install

The reason these campaigns work is that hiring is a context where installing unfamiliar software feels routine. That logic does not stop at take-homes, and it applies to tools that help candidates too, Control included. Control is a desktop application for Windows and macOS, and the only build worth trusting is the one from trycontrol.app itself — not a mirror, a chat attachment, or a "recruiter-provided" installer. Check the domain, check the platform support against what your machine actually runs, and be skeptical of any interview tool distributed outside its vendor's own site.

Browser-based assessments are a different risk profile entirely, because the code runs on the platform's servers rather than yours. If you want the boundary between the two, what interview websites can and cannot see about your running apps covers the browser side, and what to check when an assessment ships as a desktop app covers the case where a legitimate employer does ask you to install something.

What to do with this

The base rate still favors legitimacy: most take-homes are real, and refusing to run code would cost you far more interviews than it protects. The workable position is not suspicion, it is containment — make running an unknown repository a cheap, reversible act by doing it somewhere disposable, every time, without deciding in advance which assignment deserves it. That habit costs you a few minutes per take-home and removes the entire attack class, including the variants that have not been documented yet.

If your next take-home is one where the harder question is what tooling you are allowed to use rather than whether the code is safe, start with the 2026 rules for AI use in take-home assignments.