When a Job Interview Becomes a Cyberattack

I almost walked into a very sophisticated fake-job cybersecurity attack recently.
I received a LinkedIn outreach for a fully remote Technical Advisor / Product role involving AI, blockchain, Web3 gaming and staking. The pitch was personalized to my background.
I researched the opportunity and the details before proceeding. What I found was remarkable: another developer, Max Koretskyi, documented the attack pattern for an almost identical job description. In his case, the “interview” eventually became an attempt to get him to open a project in VS Code and run npm install in a malicious repository, which would trigger an npm lifecycle hook and execute attacker-controlled code.
I can’t prove that the person who contacted me had malicious intent. But the similarities were far too specific for me to continue, so I walked away. What interested me most was not the fake recruiting pitch itself, but the engineering of the attack, because it exploits perfectly normal developer behavior.
The Attack Chain
Every step can look perfectly legitimate. The attack chain is deceptively simple:
1. Consulting Engagement
Client outreach → discovery call → “review our codebase and propose an AI solution” → clone or open the GitHub repository → run a routine development command such as npm install → malicious code executes.
2. Job Interview
Recruiter outreach → technical interview → “review this sample project created for the technical assessment” → clone or open the GitHub repository → run a routine development command such as npm install → malicious code executes.
Why It Works
In Max’s documented case, the attacker did not need the victim to knowingly install an obviously malicious package. The repository itself defined an npm lifecycle hook, so running a routine npm install would automatically execute malicious code contained in the project.
Why is this effective? Because the attacker is exploiting trust in a workflow rather than trust in a file. Engineers routinely clone repositories, install dependencies, open projects in VS Code, and run unfamiliar code while evaluating products, joining teams, or consulting for clients. The social engineering simply creates a credible business reason to do something technically dangerous.
Microsoft has documented the broader campaign as “Contagious Interview”.
Reducing the Risk
A useful reminder for anyone interviewing for technical roles, taking on consulting engagements, or otherwise reviewing code from an untrusted repository:
- Treat code supplied during a recruiting or consultation process exactly like any other untrusted code. A recruiter, company name, Calendly invite, Google Doc, GitHub repo, and professional-looking interview process can all look legitimate. The social engineering is very convincing. However, a realistic-looking GitHub repository does not make code safe to execute.
- If you genuinely need to inspect or execute unfamiliar interview code: never run it directly on your primary development machine. Isolation matters beyond malware prevention. Your normal development machine may contain
.envfiles, API keys, cloud credentials, SSH keys, source-control tokens, password-manager sessions and other things an attacker would love to steal. A disposable sandbox with no personal credentials, no host filesystem mounts and restricted network access can dramatically reduce the risks.
A Container Is Not Automatically a Sandbox
Simply putting suspicious code in a normal Docker container does not automatically make it safe. Containers can still be given access to host resources. Docker’s own documentation notes that bind mounts are writable by default and can allow processes inside a container to modify files on the host. Adding elevated capabilities or other privileged configuration can weaken isolation further.
Microsoft recommends using a dedicated, isolated environment such as a non-persistent virtual machine for coding tests and take-home assignments. A purpose-built remote sandbox can serve a similar purpose. For example, Modal Sandbox is designed for executing untrusted code and allows outbound network access to be blocked or restricted.