DPRK

Scams

DPRK Contagious Interview: Betfin-Pro1 Malware Campaign

Feb 17, 2026 | Updated Feb 19, 2026 | 11 min read

Betfin-Pro1 reveals DPRK-linked blockchain malware abusing fake Web3 recruitment, VS Code auto-tasks, and Binance Smart Chain smart contracts to host on-chain payloads for stealthy C2 and remote code execution targeting developers.

DPRK CONTAGIOUS INTERVIEW: BLOCKCHAIN-HOSTED MALWARE ON BSC

In February 2026, zeroShadow investigated a targeted malware campaign that weaponized a fake recruitment process to compromise software developers.

The operation stood out for hosting its malicious payload directly on Binance Smart Chain (BSC), using smart contract storage as resilient command-and-control infrastructure. On-chain forensic analysis and bytecode comparison link this infrastructure with high confidence to previously documented DPRK Contagious Interview activity.

The attackers impersonated a legitimate Web3 gaming platform, Betfin, and approached developers with a job opportunity. Victims were instructed to review a GitHub repository in Visual Studio Code, explicitly told not to execute anything.

Once the victim opened the repository in VS Code and trusted it, the infection triggered and at that point, no further user interaction was necessary for the attack chain to succeed.

The repository contained a malicious VS Code task configured to execute automatically on folder open. This triggered a Node.js backend that retrieved obfuscated JavaScript stored on-chain via a Binance Smart Chain (BSC) smart contract. That payload then beaconed to an external command-and-control (C2) server and enabled remote code execution.

This campaign demonstrates a mature combination of:

• Recruitment-themed social engineering
• IDE auto-execution abuse
• On-chain payload hosting
• Remote stage-two infrastructure
• Developer-focused targeting

The Initial Lure: Fake Recruitment Campaign

The attack began with direct outreach to developers via LinkedIn.

The persona posed as a recruiter for “Betfin,” a real Web3 gaming platform that offers white-label partner contracts. The attackers leveraged publicly available branding, documentation, and terminology from Betfin’s official website to build credibility.

The recruitment flow included:

• A LinkedIn recruiter persona
• A GitHub organization impersonating Betfin
• A repository named bet-poker-ser
• A Calendly scheduling link branded as Betfin
• A technical “manifesto” PDF hosted on Google Drive

The victim was advised:

“You don’t need to run anything. Just open the repo in VS Code for a short review.”

That instruction was deliberate. The attack depended on VS Code automatically executing workspace tasks configured to run on folder open.

Malware Analysis

On Friday 6th Feb, 2026, we identified and investigated a sophisticated supply-chain intrusion that required zero user interaction beyond trusting and opening a malicious file in Visual Studio Code (VS Code), used blockchain infrastructure to evade detection, maintain persistence, and execute entirely in memory; resulting in no forensically recoverable artefacts on disk. This intrusion also implemented dynamic payload delivery for targeted attacks.

The malware family seems to be custom, though it falls largely into the stealer class of malware, designed to target software developers who inspect and use Github regularly.

Fileless execution allows for evasion of static signature detection from antivirus and EDR solutions on the endpoint, and blockchain immutability allows for mostly anonymous payload storage.

The Github repository linked at hxxps://github[.]com/Betfin-pro1/bet-poker-ser contained a sophisticated multi-stage malware delivery mechanism disguised as a legitimate cryptocurrency poker game project. The malware used VS Code's auto-execution feature combined with blockchain-based payload delivery to achieve near zero-interaction compromise. Opening the repository in VS Code triggered the infection chain without any user interaction.

Key Findings:

• Once the repository is trusted and opened in VSCode:
  • Zero-click execution via VS Code .vscode/tasks.json with runOn: folderOpen
• Blockchain-based C2 using Binance Smart Chain smart contract as payload storage
• In-memory execution using JavaScript new Function() - no malicious files written to disk
• Host fingerprinting and remote beacon to C2 server
• Heavily obfuscated second-stage payload fetched dynamically

Metadata:

• Repository Name: bet-poker-ser-main
• Primary Language: JavaScript (Node.js)
• Disguise: Legitimate-looking Web3 poker game with React frontend and Node.js backend
• Entry Point: .vscode/tasks.json → npm install → node server.js → socket/index.js
• Architecture: Cross-platform (Windows, Linux, macOS)

The Repository

The Github repository hosting the payloads was a new account created on Thursday, 29th January 2026, containing only a single repository, with no followers or stars. As of Friday 6th February, 2026, the repository was no longer active.

The repository itself, called bet-poker-ser, contained the entirety of the payloads and malware used throughout the intrusion. Presumably, a developer would be phished, or clone this repository believing it to be legitimate. The repository at the time had five contributors. After investigating these accounts, there was no clear way to tie them to identifiable indicators through open source intelligence collection.

Initial Access

Once the developer downloads or clones the repository, it's normal practice to open it in an IDE, in this case Visual Studio Code, being one of the most popular; which threat actors were likely counting on when they put this payload together.

When the victim opens a new repository, VS Code will normally show a pop-up asking whether they trust the folder, clicking “Yes, I trust the authors” will open the folder as normal and trigger a zero-click execution chain from that point on. If they were to click “No, I don’t trust the authors”, the folder will still open in restricted mode – so the code won’t execute.

If this repository was used as part of a Contagious Interview or unrelated social engineering campaign, it stands to reason that a victim may easily fall for this attack and trust the authors.

File: .vscode/tasks.json

To begin the analysis of the files, the repository contains a VS Code tasks configuration that automatically executes when the folder is opened:

The execution flow of this stage is:

• Developer clones the repository and opens it in VS Code
• VS Code automatically executes npm install --silent --no-progress (hidden from the user)
• VS Code then executes node server.js in the background (hidden from the user)
• Server starts and loads socket/index.js which contains the malicious code

Blockchain Payload Retrieval

File: socket/index.js (Specifically lines 47-105)

Next, the malware connects to a Binance Smart Chain smart contract to retrieve an obfuscated JavaScript payload, shown below:

The payload execution function is shown below:

Commentary on the TTPs

The TTPs from this stage of the intrusion shows as follows:

1. Blockchain as Dead Drop Resolver:
   1. Smart contract stores the malicious payload
   2. Immutable and censorship-resistant
   3. Appears as legitimate blockchain interaction
   4. No hardcoded C2 domains in the repository code
2. In-Memory Execution:
   1. Uses new Function() to execute code from string
   2. No files are written to disk
   3. Capability to evade file-based AV scanning
   4. require access gives full Node.js API access (filesystem, network, child processes)
3. Dynamic Payload Delivery:
   1. Attackers can update payload on-chain
   2. Different payloads can be served to different victims
   3. Single repository can deliver targeted attacks

Blockchain Payload Retrieval (Smart Contract)

Contract Address: 0x5dbBAA6359C115FB0BCA334b06a1109979063972

Network: Binance Smart Chain (BSC) RPC Endpoint .

This campaign employed a Binance Smart Chain smart contract as a censorship-resistant payload storage and delivery system. The contract, deployed at address 0x5dbBAA6359C115FB0BCA334b06a1109979063972, implements a simple storage retrieval function:

This function retrieves obfuscated JavaScript payloads stored in numbered storage slots within the contract.

Despite the parameter name slotId being referenced as "transactionId" in the malware code, this is a misnomer, it simply identifies a storage index, not an actual blockchain transaction.

The attacker pre-loaded storage slot 1 with the obfuscated JavaScript payload during contract deployment. When the malware executes, it uses the ethers.js library to query the contract:

Behind the scenes, ethers.js encodes this function call into bytecode (function selector 0x946b5793 plus the ABI-encoded parameter), sends it as a JSON-RPC eth_call request to a BSC node, and decodes the returned hex data back into the obfuscated JavaScript string.

The retrieved payload is then executed in-memory using `new Function('require`, payload)`, providing it full access to Node.js APIs. This approach is particularly effective for attackers because blockchain storage is immutable (cannot be taken down by law enforcement), permanently available (blockchain nodes maintain 99.9%+ uptime), and appears as legitimate Web3 traffic.

The query is read-only (view function) and requires no gas fees or wallet connection, making it completely passive and undetectable as malicious activity without prior knowledge of the contract address. The payload stored in slot 1 contains heavily obfuscated JavaScript (Stage 2) that implements system fingerprinting (hostname, MAC addresses, OS information) and establishes a beacon to the C2 server at hxxp://163[.]245[.]194[.]2:3000/api/err every 5 seconds, awaiting a conditional Stage 3 payload delivery, presumably based on victim profiling.

Payload Analysis

The JavaScript payload retrieved from the blockchain was heavily obfuscated using the javascript-obfuscator tool with string array encoding and hexadecimal indexing. The obfuscation employed several anti-analysis techniques:

• String array storage: All string literals are stored in a centralized array rather than inline
• Hex-encoded indices: Array lookups use hexadecimal offsets (e.g., m(0x94)) instead of direct references
• Offset calculation: A base offset of 0x6b (107 decimal) is subtracted from all indices
• Control flow flattening: Logic is wrapped in while(!![]){try{...}} patterns
• Dead code injection: Random alphanumeric strings injected throughout

We wrote the below script to obtain the JavaScript payload from the blockchain:

When looking at the payload, it was clearly obfuscated using a number of simple, non-custom techniques, including the array storage:

The payload made use of look up functions during its own deobfuscation process:

To deobfuscate the payload, we wrote a script that follows the code's logic. When the code calls m(0x93), the calculation proceeds as follows:

1. Convert hex to decimal: 0x93 = 147
2. Subtract offset: 147 - 107 = 40
3. Lookup array index 40: s[40] = `'axios'`

Deobfuscation revealed that the obfuscated code imports the axios HTTP library, collects system information via Node.js os module calls, and constructs C2 communication logic.

Key strings were reconstructed by identifying hex patterns. For example, what’s shown below is the deconstructed C2:

Running the deobfuscation script provided the following output:

The full deobfuscated payload is below:

The deobfuscated code revealed a multi-function malware component that operated in three distinct phases: system fingerprinting, C2 communication, and conditional Stage 3 execution.

The payload began by filtering out null MAC addresses (00:00:00:00:00:00), targeting physical machines, and gathering host information through os.hostname() – alongside OS type, release version, and platform.

The connection details were also shown with the C2 IP address with transmitted parameters:

• C2 Endpoint: hxxp[://]163[.]245[.]194[.]2:3000/api/err
• Method: HTTP GET with URL parameters
• Frequency: Every 5 seconds (5000ms via setInterval)
• sysInfo - System fingerprint (JSON)
• exceptionId - Static value 'env99'
• instanceId - C2-assigned tracking number (starts at 0)

The C2 server evaluates the victim fingerprint and responds with one of two outcomes. The first possible outcome receives only an instanceId for tracking and continues beaconing without further compromise.

The second possible outcome suggests that a Stage 3 payload disguised in an error response (status: 'error' with payload in message field), which is then executed in-memory via new Function('require', payload), granting the attacker full Node.js API access including filesystem, network, cryptography, and child process capabilities.

At the time of writing, the C2 server refuses connections but is alive, so currently there is no way to obtain the stage 3 payload – furthermore, the Github repository is no longer online.

Command and Control

The primary C2 server is located at:

IP Address: 163[.]245[.]194[.]2 Port: 3000

Beacon Endpoint: hxxp://163[.]245[.]194[.]2:3000/i/err*/api/err

There are a few important things to point out regarding TTPs from this attacker:

• No hardcoded C2s in the repository
• All C2 logic is fetched dynamically from the blockchain, making end to end static analysis impractical
• There is conditional payload delivery (suggesting specific and well thought out targeting based on a pre-selected victimology)
• In terms of code obfuscation, error messages use misleading names ("ensureWeb error", "NFT avatar")
• Execution is silent, blockchain usage for OPSEC suggests reasonably mature tradecraft

Credentials and Configuration

File: config.js

We identified credentials for a MySQL database (likely either a compromised database, honeypot, or OPSEC blunder):

Additional Smart Contract Addresses:

• contractAddress: 0x98Ff86eD5B0dDd3C85115845A90A6066C25bedf9 (purpose unknown)
• nftContractAddress: 0x5dbBAA6359C115FB0BCA334b06a1109979063972 (malicious payload storage)
• clientDepositAddress: 0xEfcd2e9ca6483147A25a106C654a6E557eb8f916

Package Installation for Persistence

File: package.json

Package.json contains NPM lifecycle hooks that could be used to maintain persistence in memory:

The prepare script runs automatically during npm install and attempts to:

• Start server in background on Windows (start /b node server)
• Start server in background on Linux/Mac (nohup node server &)

This ensures the malicious server runs immediately after dependency installation.

Infection Mitigation Actions:

• Quarantine all hosts that cloned the repository
• Kill all Node.js processes spawned from VS Code
• Check network logs for connections to C2 infrastructure
• Review VS Code workspace trust settings

Blockchain Analysis

The malicious contract that stored the malware payload on Binance Smart Chain was 0x5dbBAA6359C115FB0BCA334b06a1109979063972 was created on 26 January 2026 at 08:47 UTC .

The contract was created by 0x6DF64cdB34Dc020c7443075af926bca4Bf53d76F, so we can infer that this address is also controlled by the malware deployer. 0x6DF6 also created two other contracts 11 minutes before deploying 0x5dbB.

This reveals that 0x6DF6 created the following contracts:

1. 0xA1D32c4921476b51567e4cAB3019462362061f34
2. 0xeE6A26721A936CDe04a8A980DF50EB7377581f61

And looking for matching bytecode across all EVM chains identified further deployments on BSC:

1. 0xf956Bf2C17E4382A4f25C67190D94046C288AA79
2. 0x106726d055Cd130b6d3fEF490D289F2b8DC38CFE
3. 0xFEC8BB4Ffea4b71dbcbf55DBfF98ac15Ed3BEa35
4. 0xa4eAA10333f463578E380f7b2dF6Dfaf435454BA
5. 0xD2F5Caa9c677d5BE6d7d9a6F90617dA6ad8b9448
6. 0x2e1aa1dA046c6008A2edc748b2995714Da39f009
7. 0x928874BE177c37a7bFE82F6e8e2cE1d0c752279f
8. 0x9C4964C3601909d0eeE970a8a9cAE4836Bdf27EF
9. 0xb0a18a9f3a09e0589572e92528624553A34CD36f
10. 0xE251b37Bac8D85984d96da55dc977A609716EBDc
11. 0xa860C1b3d7E06697677149400891368c53ACc04B
12. 0x1B24549c3C970F9f39183419166Dbd81FcEfDf0f
13. 0xD898ABEcEa7240B4D1aE4462E9035Ca7C30b7e99

All 16 contracts were identical, providing the malware with resilience and reliable censorship resistant infrastructure.

When looking at the source of funding for these contracts we identified cross chain bridging of assets across Ethereum and Base to BSC using MetaMask, Relay and Across bridges to move gas funding for the contracts.

Contract creator 0x6DF6 (BSC) was funded via Metamask and Relay, from the same address on ETH, with funds tracing back to a withdrawal from an unknown service.

Similarly, contract creator addresses 0x808B765288f56B2defb1bB18e929bF9B2558C368 and 0x2CC496E4228A158630091fBB095950c1dFB28D76, also utilised MetaMask and RelayLink bridges, as well as Across Bridge, to bridge funds from Ethereum, to Base to Binance Smart Chain, all at address 0x2CC4. Funding for the contract creation can be further traced back to two addresses:

1. 0x4180C3644548E28e0BAcbC3AeD2Eb9fd80B5C1aC
2. 0x98313dd41b1ca9B3Ff4F78fCFeBD9Fc8f7eE64CC

Open-source research links accounts on x.com to these addresses, suggesting they are likely associated with compromised developers, likely through the previously mentioned methods, rather than being linked to threat actors or malware infrastructure.

Funding in relation to contract creator addresses 0x5c2fA52875eE40e2D515c256B494f3c714B2C984 and 0x7cCf6F6B04495eE119Dc154446850F9688E3E444 followed a different pattern, with gas funding received from 0xd186d042eea8170bfb7fF2e11C5a938B982DDe3F.

Of note, in October 2025 0xd186 sent ~$40,000 USDT to 0x1B1A575a581404500B013be858Ee9AFfffd21997. 0x1B1A has received funds from a number of sources reported as stolen funds, including from the Seedify Bridge hack (September 2025), attributed to DPRK.

Further investigation regarding the source of funds at 0x1B1A identifies multiple transactions, both direct and indirect, which can be attributed to reported stolen funds - much of which is reported as result of the similar methods described in detail above. The majority of funds received at 0x1B1A have been sent on to intermediary addresses before being bridged to the Tron network, utilising Symbosis and Butternetwork, a pattern previously reported by zeroShadow in relation to DPRK, Contagious Interview activity.

In summary, although blockchain analysis alone cannot definitively confirm the purpose of the transaction from 0xd186 to 0x1B1A, this payment establishes a clear connection between the two addresses. Furthermore, the funds sent to 0x1B1A are linked to multiple thefts, including the Seedify hack, which has been publicly attributed to DPRK's Contagious Interview group and shares similar MO’s with the attacks discussed. A final link to suspected Contagious Interview activity is the subsequent laundering of funds from 0x1B1A, which follows the identical pattern of money laundering observed and previously documented.

Indicators of Compromise