Contagious Interview: Fake Coding Tests and Execution Triggers

A take-home coding test can run a loader during installation, startup or checkout. This article follows the recruitment bait and the three execution paths found in the examined projects.

This is the entry-point analysis. The companion investigation into public server source, infrastructure and payloads follows the delivery chain beyond the coding test.

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.

• Frozen: 436 repositories under 374 accounts carry the loader, a hook lure or server source at a pinned commit; 44 of the 51 hook lures still had the hook when proven.
• Operators active: two staging-server repositories received commits on 31 October (01:15 and 01:33 UTC); one hook-lure repository removed its hook on 31 October (its proof row keeps the earlier commit).
• Public: 16 of the 18 infrastructure repositories; all 51 hook-lure repositories; the job ads were still open.

On 30 October every repository in this campaign's lists was read again at a pinned commit. Each was recorded with its commit, matched file and git object id. 436 repositories under 374 accounts passed, 49 of them added on 31 October:

This is a different measure from the 256 used elsewhere on this page. 256 counts loaders that are byte-identical to an analysed sample in the operators' 61 template families, re-checked on 27 October. 382 is the 30 October proof pass plus 49 loader repositories that my daily search found on 31 October with the same rule. It also counts redistributed copies and other listed loader hits.

The fifteen server-source repositories described in the infrastructure companion were proven earlier from their full history and are not repeated in this table. 28 repositories no longer show the evidence at their current commit, 7 of them hook lures, and 3 were deleted. They are not counted. Six hook lures keep the hook in .github/githooks/post-checkout; my first rule looked only in .githooks/, so they were added on the evening of 30 October.

Fake recruiters use take-home coding exercises to deliver malicious code to developers. I examined public repositories, historical platform events and infrastructure records, alongside preserved samples that I analyzed offline. The material connects coding-test lures with staging infrastructure and with JavaScript payloads whose capabilities are consistent with the publicly reported OtterCookie lineage.

The most unusual observation: the operators keep the source code of their own staging and payload servers in public GitHub repositories. That code gives researchers a second view of the infrastructure, and its commit history dates each change.

The chain is not equally strong at every step. A URL inside a hook, for example, can be directly observed in a file; that does not establish how the archive reached a candidate or what a server returned at runtime. This article distinguishes those observations from supported links and open questions.

Two job advertisements on a public web3 job board used the name "ParallelChain Labs", which resembles the legitimate company ParallelChain Lab. They were posted on 8 and 13 September 2026. Both were later deleted from the board but are preserved in its public archive. They direct candidates to an address and a Telegram handle under parallelchain-labs[.]com. Only these two of 1,214 archived posts match the template.

The domain was registered on 7 September 2026, and a TLS certificate was issued on 8 September, about three hours after the first post. A look-alike, parallelchain-lab[.]com, followed on 22 September.

A second persona borrows a real brand. Between 22 August and 15 September 2026, ten posts on eight job boards hosted as GitHub issue trackers advertised a "Senior Solidity Smart Contract Engineer" role at "BitAngels", the name of an existing investor network. Nine of them were opened by one GitHub account, and that same account owns the source of a staging server and of a payload server (see the account relationships in the companion analysis). Four of its posts were still open on 29 October. The tenth post, with identical text, came from a different account whose control I could not establish.

Thirteen coding-test ZIP archives, in a repository of an account linked to the server infrastructure, carry a Git hook that downloads a script from parallelchain-labs[.]com. The operators' own server source also added that domain as a staging host on 7 October. The shared domain supports a connection between the advertised persona and the archives. The material does not show how those particular ZIP files were delivered to candidates.

The most common loader was found in an application file named errorHandler.js.

• It exports a function, errorTimeHandler(), that builds a URL from base64-encoded environment values and requests it with a fixed header (x-secret-header: secret).
• It runs whatever the server returns in its error response through Function.constructor. GitLab documented this pattern earlier [6].
• It fires when the application's code calls that function. In most template families, the call is referenced from the validator middleware, which was not verified for every repository.

About the code excerpts. They are shortened and made non-functional on purpose: addresses are defanged (hxxp, [.]), encoded values are replaced with <redacted>, and // ... marks omitted lines. Comments starting with ← are mine. I took them from files I examined statically; nothing was run.

Here is the core of the most common loader version (blob 39608990…):

The values it reads sit among ordinary-looking sample settings in the project's .env:

I found the loader in 256 template repositories, and in 15 more owned by accounts linked to the infrastructure. A public copy does not prove anyone ran it.

Across the template history (508 configuration versions), one loader file stays byte-identical from July 2025 to October 2026. Only the configured staging host changes, in this order:

api-server-mocha → gd.tracelic → y-lilac-sigma → walter-server / server-victory5 → server-azure-tau → tsoftlabs

That is a statement about the examined files, not proof that every related project had a single human operator.

A relative of this loader is older still. A single-repository organization created on 6 June 2025 holds an assessment project whose server/config/runtimeConfig.js decodes an environment value, requests it, and runs the response through Function.constructor when the server starts. Its configured host is bs-production[.]up[.]railway[.]app. It is the earliest malicious artifact of this cluster I have found. On 29 October I also found four more single-repository owners whose only repository carries the errorHandler.js loader; three were created on the day of their repository or a few days before. I suspect the operators set them up, but I have not proven it.

Six template repositories also contained a VS Code task configured to run when a folder opens. The task referenced files presented as fonts but containing JavaScript. In two decoded examples, the task and the application loader pointed to the same staging host and campaign identifier within the same repository.

VS Code task-based lures have been documented by earlier researchers (OpenSourceMalware, SEAL, Abstract Security, GitLab) [3, 4, 5, 6]. The overlap between the two triggers in these examples is the observation here. Whether a task runs depends on the editor's trust settings and user actions; I did not execute it.

The thirteen ZIP archives each contain a complete .git directory with an active .git/hooks/post-checkout hook. The hook is identical in all thirteen and retrieves an operating-system-specific script from parallelchain-labs[.]com/settings/<os>?flag=2.

A normal clone does not copy the source repository's hooks as active local hooks. An archive that includes a pre-existing .git directory carries the hook in place. Git runs it after a checkout in that working tree; extracting the archive alone does not.

The hook is 64 lines long. Forty-five of them are generic comments about what Git hooks are for, which makes the file look like documentation. The part that runs, condensed:

A separate set of repositories, under two "BitAngels" organizations, contained a hook under .github/githooks/ that calls githooks[.]xyz. Git uses that hook only if core.hooksPath points to that directory, and when I checked them on 27 October no file in those two organizations set it.

Newer lures set it for the candidate. On 28 and 29 October I found 51 hook-lure repositories in 12 organizations created between September and October 2026: "hiring test" and "live coding test" organizations, and later BitAngels-themed ones. They ship a VS Code task that runs when the folder is opened and stays hidden:

The checkout fires the repository's own post-checkout hook, which has the same structure as the archive hook above: a block of comment lines, then curl or wget piped into a shell, per operating system. Once a candidate opens and trusts the folder in VS Code, no further action is needed. Each group of organizations points at its own staging host:

Every one of these hosts also appears in the operators' server source or in the same domain registration batches. All 51 repositories were still public on 29 October.

The hook contents were inspected; I did not run them. Prior reporting had already documented folder-open tasks [3, 4, 5], malicious hook lures and archives containing live hooks [11]. What is new here is the set of repositories and hosts, not the technique.

Before opening or running an unfamiliar take-home project:

1. Inspect archives for .git/hooks/, .githooks/, .github/githooks/ and other setup scripts. Treat a ZIP containing a .git directory with non-sample hooks as untrusted, and do not perform a checkout inside it.

2. Review .vscode/tasks.json for folder-open tasks, and examine files presented as fonts or images if a task tries to run them with Node.js. A task that runs git config core.hooksPath is a red flag. Use the editor's workspace trust controls.

3. Review application setup and environment-driven loaders before installing dependencies or running the project. Look for Function.constructor or eval applied to remotely retrieved code, and for base64 values in .env that decode to unexpected URLs.

4. Hunt where telemetry permits:

   • for the header x-secret-header;
   • for the paths /api/ipcheck-encrypted/ and /settings/;
   • on macOS, for the file ~/Library/LaunchAgents/com.user.chrome.cdp.plist;
   • for outbound traffic to the listed C2 addresses on ports 8085–8087.

   Validate each match in context: shared infrastructure and common paths can produce false positives.

Use a separate, trusted device for any password or key changes. If the machine belongs to an employer, involve their incident-response team before changing anything.

Look for these traces. Each one comes from the operators' published code or from my static analysis; not every infection leaves all of them.

• A .vscode folder in your home directory (%USERPROFILE%\.vscode on Windows, ~/.vscode on macOS/Linux) containing files you did not create. Examples: vscode-bootstrap.cmd, env-setup.js or env-setup.npl, or a package.json with axios, socket.io-client, clipboardy or sql.js.
• On macOS, the file ~/Library/LaunchAgents/com.user.chrome.cdp.plist, or the logs /tmp/chrome-cdp.stdout.log and /tmp/chrome-cdp.stderr.log.
• Google Chrome running with --remote-debugging-port when you did not start it that way.
• Node.js processes connecting to remote ports 8085, 8086 or 8087.
• Unexpected background node processes started from your home directory.

Assume these were exposed and change them. The stealer targets each of them:

• passwords saved in browsers;
• crypto-wallet extensions (move funds using a new seed on a clean device);
• SSH keys;
• cloud credentials (~/.aws and similar);
• API keys or tokens in your shell environment or .env files;
• GitHub and npm tokens.

Rebuild. A reinstall is the reliable way to remove the remote-access component. Deleting the files above does not guarantee a clean system.

This campaign does not exploit a software vulnerability. It exploits a routine step of hiring: a candidate receives a project, installs its dependencies and runs it, often under time pressure and on the same computer that holds their browser sessions, password manager and crypto wallets. Each of those steps looks normal, which is why the technique keeps working.

Technical controls alone do not close that gap; people who hire and people who apply need to know the pattern. What I would ask readers to pass on:

• Candidates: run any take-home test in a disposable virtual machine, container or cloud workspace with no saved logins. Before running anything, read package.json scripts, .vscode/tasks.json and any Git hooks. A recruiter who insists the project must run locally and quickly is a warning sign.
• Recruiters and hiring teams: send tests from your own organization's repository and say so in writing, so candidates can tell a real test from a copy.
• Security and IT teams: treat developer job hunting as part of the threat model, and include this lure in awareness training alongside phishing.
• Everyone: if you received a test like this, report the repository to the platform that hosts it. Each report removes one copy that someone else might run.

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.

The companion indicator inventory retains the reviewed staging hosts, payload hashes and historical command-and-control addresses. Indicators describe observed configurations, not confirmed execution.