Contagious Interview: Public Servers, Infrastructure and Payloads

The operators of a DPRK-linked malware campaign keep the source code of their own servers on public GitHub, and its commit history exposes their infrastructure.

• Seventeen repositories hold the staging and payload servers that deliver an information stealer to developers who take fake job-interview coding tests.
• In the first fifteen, 375 commits date every change of hostname and deployment.
• On 27 October 2026, between 02:50 and 04:06 UTC, the operators pushed a new malware build with macOS persistence. Early on 29 October they pushed again, moving three staging servers to new hosts.
• The 27 October template recheck found 256 repositories with a byte-identical loader; the 29 October hook-lure inventory recorded 51 repositories. These are historical subsets, distinct from the broader 383-repository proof pass on 30 October described in the entry-point analysis.

I did not execute anything or contact the operators' servers. This article separates what I directly observed from what I infer.

This is the infrastructure analysis. Start with the fake coding tests and execution mechanisms for the recruitment bait and initial trigger.

The proven set was closed on 1 November 2026 with what had been found up to 31 October 2026, 17:59 UTC; repositories found after that are tracked separately and are not in these figures. The full proof pass at pinned commits ran on 30–31 October. On 1 November 2026, 18:23 UTC a read-only GitHub API recheck covered the 162 repositories, 73 accounts and 12 issues that are tracked one by one (operator repositories, Shai-Hulud accounts, phishing issues), not the whole set.

• Public: 16 of the 18 server-source repositories; the two missing ones disappeared with their account before 29 October.
• Maintained: two staging servers received commits on 31 October (01:15 and 01:33 UTC), each changing index.js; another one on 29 October at 08:12 UTC. The new code was not read.

My inventory, reconciled on 27 October 2026 and extended on 29 October:

• 267 public coding-test repositories across 61 template families.

  • 256 still contained a loader when re-checked on 27 October (12:41–12:45 UTC). The loader file was byte-identical to an analyzed sample in every case.
  • The loader configuration resolves to a staging URL in 241 of them.

• 17 server-source repositories. The first 15, holding eight staging and seven payload servers, have 375 recorded commits from March to October 2026; two more, a staging server and a payload server under one account, were found on 29 October.

• 51 hook-lure repositories in 12 organizations, in which a hidden editor task arms a Git hook when the folder is opened (29 October).

• 35 payload files analyzed, from 157 payload versions overall:

  • 30 files present on 26 October;
  • 122 earlier versions from the repositories' history;
  • 5 versions pushed on 27 October.

  They belong to one code family with four builds, plus an older generation.

• 15 command-and-control (C2) IP addresses configured across those versions. 13 had no ThreatFox record when checked.

• 13 coding-test ZIP archives containing a .git directory with an active post-checkout hook.

These are counts of what I identified, not estimates of all activity or of confirmed infections. How each one was counted:

Seventeen repositories contain the source of Express applications that make up the delivery chain:

• Staging servers (8). They answer /settings/{windows,linux,mac}?flag=N with a script that downloads and starts a Node.js program in the background. Requests whose user agent looks like a browser or Postman receive a harmless IP-information decoy instead, so the abuse is not visible when the URL is opened in a browser. In the October 2026 version, the setup script sends the requester's full environment variables ({...process.env}) to the payload host before running the code it gets back.
• Payload servers (7). They return one of several multi-megabyte obfuscated JavaScript files kept in a folder named 10/. They also contain code that records each request (client IP, location, host name and user name) in a Firestore collection, and an operator view at /mine/list.

Excerpts from the index.js of one staging server, as last changed on 23 October 2026 (489 lines). First, the decoy for anyone who opens the URL in a browser or in Postman:

Then what a request from curl or wget receives, here for Windows. The Linux and macOS variants end with nohup bash ... > /dev/null 2>&1 &, so the next stage keeps running in the background:

And the setup script's last step, which sends the requester's environment variables and runs the reply:

The repository history shows how configured hosts changed. It records:

• 48 hostnames: 22 on vercel.app, 3 on onrender.com, 3 Firebase projects and 20 custom domains;
• 28 Vercel deployment targets, named by Vercel's own GitHub integration in commit statuses.

A commit shows what a version of the code contained. It does not establish that the version was deployed, that a service was live, or what it returned to a particular client.

The servers are still maintained. On 27 October 2026, between 02:50 and 04:06 UTC, four payload repositories owned by four different accounts each received a commit replacing one payload file. Vercel reported a successful deployment within one to two minutes of each commit.

Two days later, on 29 October between 00:02 and 02:54 UTC, three staging-server repositories and one payload-server repository received new commits. The staging servers moved to view-my-result[.]lol and jitnad[.]biz, and a new Vercel project appeared.

Two more server-source repositories belong to the account that posted the BitAngels job ads. One is a staging server with the same /settings/:type route, which moved from githooks[.]xyz to git-node-update[.]online (registered 12 October 2026) and was deployed eleven times to Vercel between 7 and 23 October. The other is a payload server with the /mine/list panel; its middleware files are byte-identical to those of an earlier staging server. One account and one host therefore join the job ads, the BitAngels hook lures and the server code.

The presence of operator server source in public repositories was not found in the public sources checked as of 29 October 2026. This is a bounded literature-search result, not a claim that no one else has observed it.

These relationships describe accounts and recorded events. No natural person is identified.

• Continuity across accounts. An account that is no longer publicly accessible pushed a payload-server repository between 17 March and 22 April 2026, according to GH Archive. Its final commit appears in the history of a later account's repository. Two new accounts were created on 29 April 2026. One of them pushed onto a staging-server commit thirty minutes after its creation.
• User-then-organization pairs. From September 2026, four times, a new user account was followed within 1.5 to 18 minutes by an organization whose repositories only that user pushed to, in the available event window.
• Renames. Three accounts were renamed, identified by stable numeric platform IDs. One of them carried a different name in 2024.
• Lure-template distributor. An organization that distributes loader-bearing templates (sixteen of its repositories, together with its owner's, carry the loader) configured the same staging hosts that one of the staging servers adds to its source.
• Recruiter lure and npm package. A malicious npm package (OSV MAL-2026-2896, April 2026) [12] uses the same payload URL and key as a previously documented recruiter lure. The payload server behind that URL is one whose source the since-inaccessible account had pushed.

Creation timing, matching names or shared hosting alone cannot establish common human control. A shared staging host such as api-server-mocha, configured in 214 template copies, indicates the same campaign infrastructure rather than a single operator group. In total I recorded 51 distinct accounts on the infrastructure side (54 logins including old names): 32 by 27 October and 19 more by 29 October, mostly the hook-lure organizations. Thirty-seven were publicly accessible on 29 October.

Static analysis of the preserved JavaScript samples found code that targets:

• browser data and extension storage, including the MetaMask wallet;
• macOS keychain data;
• SSH and AWS files;
• clipboard contents and screenshots.

The samples also contain operating-system checks, upload endpoints on ports 8085 and 8086, and a Socket.IO control channel on port 8087. All samples share five embedded modules that are identical once IP addresses, ports and numbers are normalized.

After deobfuscation, the upload and control addresses are plain constants near the top of each sample. This one is from a B1-cdp file:

The Chrome module starts a separate, headless browser with its debugging port open:

And the password module looks for Chromium's saved-login databases in each browser profile:

The macOS module added on 27 October (build B3-cdp-la, the same in all five new versions) writes a LaunchAgent that starts that debuggable Chrome through launchd. Condensed:

Two details matter for defenders. The plist path is fixed, ~/Library/LaunchAgents/com.user.chrome.cdp.plist, and launchd writes Chrome's output to two files in /tmp. The branch also runs only when os.release(), the Darwin kernel version, is 27.0.0 or later. macOS 26 reports Darwin 25, and I did not verify which macOS release, if any, reports 27. As written, the module may therefore not run on current Macs; that reads as a feature being prepared, but it is an inference from the code.

I grouped the samples into builds:

Neither the Chrome-debugging module nor the LaunchAgent persistence was found in the public sources I checked for this lineage. LaunchAgent persistence itself is a common macOS technique. This classification reflects static inspection; successful data theft, actual network responses and runtime behavior were not observed.

The assessment that this is consistent with the OtterCookie lineage draws on module structure and on prior public reporting by Cisco Talos [2], Elastic [9] and the SANS Internet Storm Center [8], whose reports also describe the 8085–8087 port pattern. It does not independently identify a nationality or natural person.

Exact dates. Platform timestamps unless marked as commit dates; commit dates are set by the client.

Periods:

• July 2025 – October 2026: the errorHandler loader file stays byte-identical across the template history (commit dates); only the staging host changes.
• 17 March – 22 April 2026: a since-inaccessible account pushes a payload-server repository (GH Archive).
• 22 August – 15 September 2026: ten BitAngels job posts on eight GitHub-hosted job boards.
• 3 – 24 October 2026: most hook-lure organizations are created; Dynadot registrations on 8, 13 and 23 October.

This is a passive and primarily static investigation. I did not access any suspected server, C2, operator panel or victim data, and I did not execute the payloads. Consequently, current liveness, server responses, delivery to a particular candidate and actual compromise are unknown. Platform search, public archives and threat-intelligence sources have coverage gaps.

This article is part of the GitHub threat investigation. Counts are a snapshot, not evidence that the code ran on a victim's machine. The shared methodology and proof rules explain inclusion, exclusions and the independent re-check.