Cyber Threats Void Dokkaebi Uses Fake Job Interview Lure to Spread Malware via Code Repositories Our research on Void Dokkaebi’s operations uncovered a campaign that turns infected developer repositories into malware delivery channels. By spreading through trusted workflows, organizational codebases, and open-source projects, the threat can scale from a single compromise to a broader supply chain risk. By: Feike Hacquebord, Lucas Silva Apr 21, 2026 Read time: ( words) Save to Folio Key takeaways Void Dokkaebi (aka Famous Chollima) has evolved beyond single-target social engineering into a self-propagating supply chain threat. A compromised developer’s repository becomes an infection vector for the next wave of victims, creating a worm-like propagation chain through the developer ecosystem. The campaign spreads through trusted development workflows, using malicious VS Code tasks and injected code that can execute during normal development activity. When compromised code reaches organizational or popular open-source repositories, contributors, forks, and downstream projects can also be exposed. Analysis in March 2026 identified more than 750 infected repositories, over 500 malicious VS Code task configurations, and 101 instances of the commit tampering tool. Repositories belonging to organizations such as DataStax and Neutralinojs were also identified carrying infection markers. The campaign uses blockchain infrastructure for payload staging, including Tron, Aptos, and Binance Smart Chain, which puts parts of its delivery infrastructure beyond traditional takedowns. Introduction Void Dokkaebi, also tracked as Famous Chollima, is a North Korea-aligned intrusion set that systematically targets software developers who hold cryptocurrency wallet credentials, signing keys, and access to continuous integration/continuous delivery (CI/CD) pipelines and production infrastructure. As previously documented by TrendAI™ Research , the group poses as recruiters from cryptocurrency and AI firms, luring developers into cloning and executing code repositories as part of fabricated job interviews. This is a pattern independently tracked across the industry since 2024, but less attention has been paid to what happens after the initial compromise. Our analysis reveals that Void Dokkaebi’s operations do not end with a single infected developer. The compromised machine becomes a launchpad, with the threat actor weaponizing the victim’s own repositories and turning their code contributions into infection vectors for downstream developers. The result is a self-sustaining propagation chain resembling a worm’s behavior rather than a traditional targeted attack. This report details the propagation model, the malware it delivers, the scale of contamination we observed, and what organizations can do about it. The infection paths and how the worm spreads The propagation relies on two distinct mechanisms that work in tandem. The first spreads passively through Visual Studio Code (VS Code) workspace configurations that travel with committed code. The second is an active technique where the threat actor, having gained remote access to a developer’s machine, injects obfuscated JavaScript into the victim’s repositories and rewrites git history to conceal the tampering. Figure 1. Infection paths used by Void Dokkaebi, with the first flow done via VSCode and the second via active injection The initial infection begins with a fabricated job interview where the victim is asked to clone a code repository and review or run it as part of a technical assessment. The repositories are hosted on GitHub, GitLab, or Bitbucket, and appear to be legitimate coding projects. The delivery mechanism abuses VS Code’s workspace task system, a technique that has been independently documented by Microsoft , OpenSourceMalware , and Abstract Security . The attack works as follows: The repository contains a .vscode/tasks.json file with a task configured to run automatically when the workspace is opened ( runOn: folderOpen ). When the victim opens the project in VS Code and accepts the workspace’s trust prompt, the task executes without further interaction. In some cases, the task fetches the backdoor directly from a remote URL. In others, it launches a font or image file bundled in the repository that contains the malicious payload, a different execution variant that achieves the same result. The developer’s ecosystem is compromised at this point, but the worm-like behavior begins when the victim commits that code to GitHub. Whether pushing the project itself or reusing components in other work, the malicious .vscode/tasks.json is committed along with it. The .vscode folder is hidden by default in file explorers and is commonly absent from .gitignore files, making it an effective trojan horse. Any developer who subsequently clones that repository and opens it in VS Code receives the same trust prompt. If accepted, the cycle repeats. This creates a self-propagating chain. Each compromised developer seeds new repositories with the infection vector, and each new victim becomes a potential distributor. Unlike traditional social engineering where the attack ends with the initial target, here the range of infection expands with every commit. Flow 2: Active injection and commit tampering In parallel, we observed a second propagation mechanism. Users who were already compromised by Void Dokkaebi had multistage obfuscated JavaScript code added to the source code files in their repositories. The threat actor targets various configuration files and common entry points, choosing files that developers are less likely to scrutinize closely. The obfuscated JavaScript, which functions as the multistage loader described in the next section, is added to the end of the file. Whitespace is often added to push this additional code to the right edge of the screen and make it invisible during casual code review, or when inspecting code differences. Because these configuration files are evaluated as JavaScript by Node.js tooling (e.g., build tools, linters, bundlers), any code appended to them executes automatically whenever the corresponding tool runs. Figure 2. Code snippets of a GitHub repository containing the injected code Both the code injection and its concealment are performed remotely through malware installed during the initial compromise (flow 1). To conceal the tampering, the threat actor employs a Windows batch script ( temp_auto_push.bat ) that extracts metadata from the most recent Git commit, its date, time, author name, email, and commit message. They then temporarily alter the system clock to match the original commit’s timestamp. The modified commit is amended with the injected code while preserving all original authorship metadata. The --no-verify flag is used to bypass pre-commit hooks and CI/CD security checks. After the amendment, the system clock is restored, and the rewritten commit is force-pushed to the remote branch. In the git history, the injection appears indistinguishable from the original commit. Figure 3. Code snippets of the temp_auto_push.bat script In some compromised repositories, we observed both techniques being present simultaneously (i.e., the malicious .vscode/tasks.json alongside the appended obfuscated JavaScript). We believe that there were cases where developers fell victim to both propagation methods separately, but also cases where the attackers used both techniques on one victim. This “double infection” mechanism provides redundancy. The tasks.json catches developers using VS Code (triggering on folder open), while the injected JavaScript executes for anyone who builds or runs the project regardless of their IDE. Together, they guarantee malware execution. The organizational amplifier The worm-like propagation poses higher risk when it reaches developers with commit access to organizational or popular open-source repositories. We identified compromised repositories belonging to the following organizations: DataStax : At least five repositories found compromised between January 31 and February 3, 2026, which have since been cleaned. Neutralinojs : They had 8,400 stars and 495 forks, where all four repositories were force-pushed with malicious commits in a single automated burst on March 2, 2026. The commits were backdated between 5 and 35 days to blend with legitimate history, and the attack went undetected for 3 days until identified and remediated by the OpenSourceMalware team . These organizations were found carrying malicious code snippets consistent with these techniques. While we cannot confirm the exact chain of events within these organizations, the indicators are consistent with a scenario where a contributor with commit access was first compromised through the social engineering lure (flow 1), which subsequently enabled the infection of the organizational repositories (flow 2). Once a repository of this scale is compromised, every contributor, every fork, and every downstream project that depends on it becomes a potential victim. This amplifies the scope of the campaign from a single developer to an entire ecosystem. This propagation model is fundamentally different from traditional supply chain attacks, such as the SolarWinds incident that required the compromise of the build infrastructure. Here, no build system is breached. The attack exploits something far simpler: Developer workflow habits The tendency to not include .vscode folders in gitignore Not reviewing configuration files line by line Trusting the contents of their own repositories. It is also distinct from traditional network worms, which exploit software vulnerabilities to propagate. This campaign propagates through trust in development tools, in colleagues’ commits, and in open-source projects. With the propagation model established, we now turn to the malware that these infection vectors deliver. The malware in brief: DEV#POPPER RAT variant The tasks.json vector (flow 1