Threat actors behind the long-running Contagious Interview campaign were seen expanding from traditional social-engineering lures to the abuse of Microsoft Visual Studio Code (VS Code) as an execution and persistence mechanism.
According to new findings from Jamf Threat Labs, the actors are embedding malicious logic directly into VS Code project configurations, allowing code to execute as soon as a victim opens a repository and grants it “trust”.
Rather than relying on standalone malware or exploit chains, the campaign now leans on trusted developer workflows. Victims are lured to clone Git repositories, often under the guise of interview assignments or shared projects. Once opened in VS Code, weaponized configuration files automatically trigger commands that fetch and execute malicious JavaScript payloads.
Instead of targeting operating systems or browsers directly, the DPRK-linked actors are embedding themselves inside this IDE tool developers use every day, to reduce friction, evade suspicion, and achieve stealth within trusted environments.
Weaponized VS Code for a persistent backdoor
The new technique revolves around the abuse of Visual Studio Code’s tasks.json files, which are designed to automate development actions such as builds and scripts. In Jamf-observed attacks, these tasks’ definitions are modified to include hidden commands that execute automatically once the repository is opened and trusted by the user.
Those commands run shell processes that retrieve obfuscated JavaScript from remote infrastructure and pipe it directly into Node.js for execution. Jamf researchers noted that the payloads are often hosted on legitimate platforms such as Vercel, further reducing the likelihood of early detection or blocking. Once running, the JavaScript establishes communication with a remote command-and-control server and enables remote code execution (RCE).
Importantly, the backdoor does not depend on VS Code remaining open. After initial execution, the malicious code can persist independently, meaning closing the IDE does not stop the activity. This turns what appears to be a one-time development task into a long-lived foothold on the victim’s system.
Social engineering to developer trust abuse
The effectiveness of the campaign hinges on social engineering rather than technical exploitation. Victims are tricked into interacting with unfamiliar repositories as part of legitimate-looking projects. Once the repository is opened, VS Code’s built-in trust prompt becomes the key, and approving it enables the malicious task execution chain without further warnings.
Jamf researchers also observed redundancy built into the attack flow. In some cases, attackers included fallback mechanisms, such as dictionary files containing embedded JavaScript, ensuring code execution even if the primary task-based delivery failed. Additional payloads were seen being fetched minutes after the initial execution, suggesting layered persistence and ongoing control.
The researchers shared indicators of compromise (IoCs) associated with the campaign, including malicious infrastructure and artifacts observed during the investigation, to support detection. Additionally, they recommended caution while interacting with unfamiliar repositories, particularly those obtained through third parties or interview-style engagements. “Before marking a repository as trusted in Visual Studio Code, it’s important to review its contents,” they added in a blog post. “Similarly, ‘npm install’ should only be run on projects that have been vetted, with particular attention paid to package.json files, install scripts, and task configuration files to help avoid unintentionally executing malicious code.”