Red Hornet | Fake Interview, Real Malware

This hunt started with GitHub code search and followed a developer-focused compromise chain through VS Code task automation, local Git hook configuration, remote OS-specific loaders, and obfuscated JavaScript payloads.

This hunt started with GitHub code search.

The seed query looked for repositories that combined Vercel-style /settings/ routes with OS branches for mac, windows, and linux. That led to public repos where the suspicious code was not in the main app. It was in the development workflow files:

.vscode/tasks.json
.vscode/settings.json
.githooks/pre-commit
.githooks/post-checkout

The recurring pattern was:

VS Code folder open
  -> automatic task
  -> git config core.hooksPath
  -> pre-commit or post-checkout hook
  -> /settings/{mac,linux,windows} remote script
  -> JavaScript payload

Several repo families used the same idea. Some appeared to be copied project templates with a malicious overlay added later. The most useful live branch for analysis was a StockX-themed repo that reached out to tanxilabs.com.

StockX Branch

The StockX chain used a nested backend path. Its VS Code task configured Git hooks, and the hook fetched an OS-specific launcher:

https://tanxilabs.com/settings/linux?flag=2

Only the Linux route was run, and only inside a disposable VM with a fake home directory. The observed chain was:

Git hook
  -> tanxilabs launcher
  -> bootstrap script
  -> local npm install
  -> env loader
  -> ip-api-psi.vercel.app POST
  -> obfuscated JavaScript
  -> final C2/exfil infrastructure

The dynamic payload came from:

https://ip-api-psi.vercel.app/api/githook-encrypted/N3RlYW02

The VM run touched fake Chrome, Chromium, Brave, and Edge profile paths, including Login Data files. It also touched wallet-extension storage paths matching MetaMask and Phantom.

Network traffic included repeated cleartext HTTP uploads to:

45.61.148.220:8085/upload

Related logging and tasking traffic used:

45.61.148.220:8087

The npm portion looked like staging support rather than the source of compromise. The install resolved packages from registry.npmjs.org, lockfile and cache integrity matched, and follow-up import testing did not show package-level network behaviour.

Payload Structure

The large JavaScript payload decoded into three main child stages:

Browser and wallet credential collection.
Sensitive-file scanning for wallet, seed, mnemonic, and related material.
Socket.IO-style tasking, logging, and upload support.

That matched the VM behaviour. This was not just a region check or telemetry script. It was an infostealer/backdoor chain aimed at developer machines.

Side Pivot: ipregionchecker

The StockX material also exposed an app-code path:

https://www.ipregionchecker.net/api/ip-check-encrypted/3aeb34a32

That route returned a sibling obfuscated JavaScript payload. The child stages were behaviourally equivalent to the ip-api-psi branch, but the final infrastructure changed to:

216.126.237.163:8085
216.126.237.163:8086
216.126.237.163:8087

After normalising the C2 host, the child scripts were nearly identical. This connected the Git-hook branch to application-code loaders that could trigger during normal Node startup.

Later related repos used the same principle without the VS Code/Git hook wrapper. In those cases, running the expected assessment workflow, such as npm install followed by npm start, could reach the loader through ordinary imports.

Earlier Branch: spellright.dict

Another branch hid JavaScript in a file named:

.vscode/spellright.dict

The file was not a dictionary. It was obfuscated Node.js invoked by VS Code tasks. It installed packages, wrote a generated script, and evaluated remote response data.

Direct hash searches were not reliable. Better GitHub pivots were behavioural:

spellright.dict filename:tasks.json
"node .vscode/spellright.dict" filename:tasks.json
isvalid-regions.vercel.app filename:tasks.json
regioncheck.xyz filename:tasks.json

One older variant reconstructed:

https://jsonkeeper.com/b/LI1B9

Passive URLScan data showed that object returning HTTP 200 in November 2025 and HTTP 404 by March 2026. I did not fetch it live during this investigation.

Hunting Notes

The best GitHub and endpoint pivots were combinations of workflow automation and remote OS-specific routes:

runOn: folderOpen
core.hooksPath
.githooks/pre-commit
.githooks/post-checkout
/settings/{mac,linux,windows}
settings/mac?flag=
settings/linux?flag=
settings/windows?flag=

Useful domains and paths from this investigation:

precommit.vercel.app
auth-drive-google.vercel.app
tanxilabs.com
precommit-chk.vercel.app
precommit-nyx.vercel.app
gitconfig-nyx.vercel.app
ninjacode-gitconfig-v1.vercel.app
www.regioncheck.xyz
isvalid-regions.vercel.app
www.ipregionchecker.net
www.whatisip.app
ip-api-psi.vercel.app
jsonkeeper.com/b/LI1B9

For host telemetry, the useful sequence is:

Editor task execution
  -> Git hook path modification
  -> remote shell/script retrieval
  -> local Node staging
  -> obfuscated JavaScript execution
  -> browser/wallet profile access
  -> HTTP or WebSocket traffic on 8085/8086/8087

Closing

The campaign lived in developer trust paths: GitHub repos, VS Code project settings, Git hooks, coding challenge structure, and normal Node imports.

The most stable detection surface was not a single domain or hash. It was the shape of the chain: editor automation leading to Git hook execution, then OS-specific remote staging, then JavaScript that collected browser, wallet, and sensitive-file data.

Review workflow files before running unfamiliar repos. .vscode/tasks.json, .vscode/settings.json, local Git hooks, package scripts, and application startup imports all belong in that review.

Download raw IOC list