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, organisational codebases, and open-source projects, the threat can scale from a single compromise to a broader supply chain risk.

By: Lucas Silva Apr 21, 2026 Read time: ( words)

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 weaponising 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 behaviour rather than a traditional targeted attack. This report details the propagation model, the malware it delivers, the scale of contamination we observed, and what organisations can do it.

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.

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 developer’s ecosystem is compromised at this point, but the worm-like behaviour 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.

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 scrutinise closely. The obfuscated JavaScript, which functions as the multistage loader described in the 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.

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.

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), whilst the injected JavaScript executes for anyone who builds or runs the project regardless of their IDE. Together, they guarantee malware execution.

The worm-like propagation poses a higher risk when it reaches developers with commit access to organisational or popular open-source repositories. We identified compromised repositories belonging to the following organisations:

These organisations were found carrying malicious code snippets consistent with these techniques. While we cannot confirm the exact chain of events within these organisations, 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 organisational 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:

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 tasks.json vector (flow 1) acts as a straightforward downloader, fetching and executing a payload from a remote URL or bundled file. However, the obfuscated JavaScript injected into source code files (flow 2) is part of a more complex approach. It functions as a multistage loader, which is designed to retrieve and execute payloads from blockchain infrastructure. It progresses through four stages, each employing layers of string shuffling, hexadecimal obfuscation, and character swap algorithms to hinder analysis.

The loader queries the Tron blockchain API to fetch a transaction from a hardcoded wallet address. The data extracted from this transaction is used as a reference key to retrieve an encrypted payload from a Binance Smart Chain (BSC) transaction’s input data field. If the Tron query fails, the loader falls back to the Aptos blockchain as an alternative data source.

The retrieved payload is XOR-decrypted using a hardcoded key and executed via eval() or by spawning a persistent hidden background process. Across stages, the loader rotates wallet addresses and transaction hashes, allowing each stage to independently update its pointers by simply posting a new transaction to the corresponding blockchain without modifying the malware’s code.

This blockchain-based staging mechanism is particularly significant because it functions as a general-purpose delivery platform. Since the payload is retrieved dynamically from immutable blockchain transactions, the threat actor can deliver any malware from their toolset by simply updating the blockchain reference, including other malware that have been linked to North Korea, such as InvisibleFerret, OtterCookie, OmniStealer, DEV#POPPER, and BeaverTail, all of which have been observed in Void Dokkaebi’s operations. A single infected repository can serve as a delivery vector for different payloads at different times, depending on the threat actor’s operational objectives.

One of the payloads delivered through this infrastructure is a variant of the DEV#POPPER RAT (version marker 260311), a cross-platform Node.js remote access trojan (RAT) previously documented by eSentire .

The variant we analysed introduces a multi-operator session management system, where several operators can work on a compromised machine simultaneously through independent command queues. This indicates team-based operations rather than a single attacker.

The backdoor communicates with its command-and-control (C&C) server via WebSocket (using socket.io-client). It uses HTTP for file uploads, directory exfiltration, and logging, specifically through the ‘/verify-human/[VERSION]’ endpoint for heartbeat and notification, and ‘/u/f’ for data exfiltration.

These distinctive network patterns provide researchers and analysts with reliable signatures for identifying infected devices. WebSocket connections to unexpected endpoints combined with HTTP traffic matching these URL patterns on developer workstations are strong indicators of compromise.

Two aspects of this variant are directly relevant to the propagation model:

To quantify the campaign’s reach, we scanned public code hosting platforms in late March 2026. The following statistics provide a snapshot of the contamination across public repositories.

Our scan identified over 750 unique repositories containing the obfuscated JavaScript loader, identified by the global['!'] initialization marker. However, in several instances, multiple repositories were infected, resulting in a higher number of source code files being compromised.

An additional 60 source code files carried a variant loader using a different marker, (global['_V']). This suggests either an evolution of the tooling or a separate Void Dokkaebi cluster operating with modified tooling, a pattern of operational autonomy we also observed in the RAT variants discussed in earlier sections.

On the VS Code infection vector, we found 392 .vscode/tasks.json files configured as downloaders and 131 additional tasks.json files launching fake font or image files. They are a different execution variant but have the same underlying infection mechanism. Any developer who clones the containing repository and opens it in VS Code will be prompted to trust the workspace. If accepted, the malicious task executes automatically.

We found the commit tampering tool ( temp_auto_push.bat ) in at least 101 repositories. This is direct evidence that the threat actor had active remote access to the developer’s machine and deliberately chose to weaponise their repositories, regardless of whether the injected JavaScript was still present at the time of our scan.

The infected repositories (numbering more than 750) include threat actor-operated repositories and legitimately compromised users’ repositories, and possibly a mix of both. We cannot determine in every case whether the injection was performed via the commit tampering tool or through direct file manipulation.

These numbers represent what was visible on public code repositories at the time of our analysis. The actual scale of contamination is likely larger. Figure 4 does not include repositories that were identified and cleaned before our scan, private repositories not indexed by public , and forks or clones that propagated the infection to environments we cannot observe.

The numbers also represent the downstream impact of cascading propagation and not the number of individually compromised developers. A single compromised developer can infect multiple files across several repositories. Each compromised developer’s repositories became the infection source for the wave of victims. When viewed alongside the organisational cases discussed earlier, this points to a self-sustaining campaign where a relatively small, initial investment in social engineering can produce a large infection surface.

The following recommendations directly address the mechanisms Void Dokkaebi relies on for propagation and persistence. These are prioritised by impact:

Void Dokkaebi’s recent activities represent a shift in how supply chain attacks can operate. Rather than compromising build systems or package registries, the threat actor exploits the trust developers place in their own tools, their colleagues’ commits, and the open-source projects they depend on. A single compromised developer becomes the seed for an infection that propagates across personal repositories, organisational codebases, and popular open-source projects without requiring any further social engineering.

The scale of infection also confirms that this is an active and expanding campaign. Organisations that treat developer workstations and repository workflows as part of their attack surface will be better positioned to detect and disrupt this threat before it propagates.

TrendAI™ Research will continue to monitor Void Dokkaebi and related campaigns, delivering actionable intelligence to ensure your organisation remains ahead of emerging threats. Our threat intelligence, paired with advanced detection capabilities, helps keep your organisation protected against sophisticated attacks going after cryptocurrency assets and sensitive enterprise data.

TrendAI Vision One™ customers are protected from the IoCs listed in the table below.

TrendAI Vision One™ Threat Intelligence Hub provides the latest insights on emerging threats and threat actors, exclusive strategic reports from TrendAI™ Research, and TrendAI Vision One™ Threat Intelligence Feed in the TrendAI Vision One™ platform.

Emerging Threats: Fake Interview Lures Used by Void Dokkaebi to Spread Malware Through Git Repositories

Threat Actor: Void Dokkaebi

Fake Interview Lures Used by Void Dokkaebi to Spread Malware Through Git Repositories

TrendAI Vision One™ App

TrendAI Vision One™ customers can use the App to match or hunt the malicious indicators mentioned in this blog post with data in their environment.

Potential Code Commit File Created

eventSubId: 101 AND objectFilePath: temp_auto_push.bat

Outbound Connection to Potential Void Dokkaebi C2 eventSubId: (204 OR 301) AND dst: (136.0.9.8 OR 198.105.127.210 OR 23.27.202.27 OR 154.91.0.196 OR 23.27.20.143 OR 85.239.62.36 OR 83.168.68.219 OR 166.88.4.2 OR 23.27.120.142)

More hunting queries are available for TrendAI Vision One™ with Threat Intelligence Hub entitlement enabled.

The indicators of compromise for this entry can be found here .