I got offered a Web3 job on LinkedIn. The "codebase" was built to rob me.

pycanis — Mon, 03 Aug 2026 19:31:04 +0000

A stranger messaged me on LinkedIn about a job in the Web3 space. Friendly, low pressure, said it sounded like a good fit. To show me what the team was building, they shared a private GitHub repository and asked me to spend "15 to 30 minutes running it and looking around" to see whether the project made sense to me.

That repository was not a job assessment. It was a trap designed to steal from the developer who runs it. Here is what it actually was, how it works in plain language, and the red flags that let you spot this without being a security expert.

The short version

The repo looks like a real, working crypto staking app. Most of it genuinely functions. That is the whole point: it needs to be convincing enough that you clone it and run it.

Hidden inside is a single booby-trapped file, disguised as a harmless styling plugin. The moment you run or build the project on your own machine, that file executes as a program with full access to your computer. It then quietly:

steals the passwords saved in your browser,
steals cryptocurrency wallet data and browser wallet extensions like MetaMask,
hunts your hard drive for anything that looks like a secret (seed phrases, private keys, .env files, SSH keys),
and opens a hidden remote connection so the attacker can control your machine and browse your files at will.

Crucially, none of this targets the app's "users". There is no scam website draining visitors' wallets. The victim is you, the developer, the moment you try it out.

What actually happened to me

I was suspicious from the first message. A recruiter I have never spoken to, handing me a whole codebase and asking me to run it before we have even had a real conversation, is odd. Running someone's code is not the same as reading it. But the ask seemed reasonable on the surface, "just have a look", so I started to look.

Here is the part I want other developers to sit with, because it is where I nearly got caught.

I did not open the project and start typing commands myself. I asked my AI coding agent to look at the repo: check the architecture, read the code, and explain what the project is and how it works. This is now a completely normal way to evaluate an unfamiliar codebase. Delegate the first pass to the agent.

The problem: modern coding agents can run code, not just read it. To "see how it works", an agent can quite reasonably decide to build the project or start the dev server. In this repo, that is exactly the trigger. The agent could have sprung the trap for me, without me ever typing the fatal command.

I watched the agent work and noticed it was mostly running read-only commands to describe the project. Then it clicked: this thing can execute code, and this is unfamiliar code I just downloaded from a stranger. That was the moment I stopped, and rewrote my instructions to tell the agent to treat the entire repository as hostile and never run or build anything. I then had it analyse the code statically, and that is when the payload turned up.

If you take one thing from this: "just ask the AI to look at it" is not automatically safe. An agent that can run commands is a loaded gun pointed at your own machine when the code is untrusted.

How the trap works (plain language, then the details)

The plain version

When you set up a JavaScript project, there are two separate steps:

Install the building blocks the project depends on (npm install).
Run or build the project to actually start it (npm run dev, npm start, and so on).

Most people assume the install step is the dangerous one. This attack deliberately leaves the install step clean and safe, and hides the trap in the run step, the thing you naturally do next to see the app working.

To style a web page, this project uses a popular tool called Tailwind. Tailwind lets projects load small "plugins". Six of those plugins are real and tiny. The seventh is the weapon. When the project builds its styling, it loads that plugin, and the plugin is not styling code at all. It is a program that runs on your computer, with your permissions, doing everything listed above.

The technical details

The malicious file is theme/js/auron-core.min.js, registered as a Tailwind plugin in tailwind.config.ts.
Its six sibling plugins are 101 to 299 bytes each. This one is 4,073,468 bytes, roughly 14,000 times larger. That size difference alone is visible from ls -la before you read a single line.
npm install does nothing (there are no install hooks). The payload fires on npm run dev, npm start, or next build, because any CSS compilation loads the plugin.
It only activates when NODE_ENV === "development", so it targets developers evaluating the repo and stays dormant in anything deployed to production, where it might get noticed.
The file is heavily obfuscated (an obfuscator.io build with a ~24,000-entry string table, control-flow flattening, and anti-debugging traps) so that a casual look, or even a naive dump, reads as noise rather than as a decoded payload.
It fetches its real dependencies at runtime with npm install ... --no-save, so they never appear in package.json or the lockfile, then spawns a detached background process by piping the script over stdin, so nothing malicious is ever written to disk.
Command-and-control runs over a bare IP address (153.75.87.26, ports 8085 to 8087) with no domain name. That means there is no DNS lookup, so Pi-hole, NextDNS, AdGuard and corporate DNS filtering never see it. A clean DNS log here proves nothing.

The whole repo is a stage set

What makes this dangerous is not cleverness in the payload, it is the plausibility around it. The attackers built an entire believable project to buy the few seconds between "run it" and "infected".

Fabricated git history. 245 commits faking a maintained project. The tell: every backdated commit is stamped at exactly 12:00:00, one per day, with templated, nonsensical messages like "Fix bug in metamask.svg" and "Polish code in placeholder.svg". The payload was slipped in under an innocuous "Polish code" commit.
A pre-emptive alibi. The README contains a tidy "Security Note" explaining away an unrelated backend folder as harmless legacy code. A comment that answers a suspicious question before you have asked it is itself a warning sign.
Load-bearing real code. Genuinely clean, competent code sits right next to the payload, in exactly the files a reviewer is most likely to open. The authenticity is the camouflage.
A facade that is hollow where nobody looks. The "smart contracts" cannot even compile. The custom theme emits CSS classes the app never uses. The "legacy backend" is 90 files of an unrelated e-commerce app used as padding.

Red flags you can spot without being a security expert

A stranger asks you to run their code. A recruiter you have never spoken to, sharing a whole repo and asking you to run it as a "task", is the entire scam. Reading code is low risk. Running it is not.
Web3 or crypto plus urgency-free friendliness. These campaigns lean on a plausible, pleasant job offer. The niceness is part of the method.
One file wildly bigger than its neighbours. ls -la is a security tool. A single file thousands of times larger than its siblings is a giant flashing sign.
Comments or notes that pre-emptively reassure you. "Don't worry, this only runs in Node, not the browser." That is not reassurance. In Node it has your filesystem, your network, and no browser sandbox.
A config file that loads local files. tailwind.config, postcss.config, next.config, vite.config and webpack.config all run real code at build time. Every require() of a local path in a config file is worth a look.
Perfect-looking but empty history. Identical commit timestamps, templated messages that do not match the files they touch, and author names with empty emails are cheap to spot once you know to look.

What to do if you have already run something like this

If you cloned and installed but never built or ran it, you are almost certainly fine. Installing alone did not trigger it. Delete the checkout, remove any dev container or volume, and report the repo.

If you did run or build it, treat the machine as fully compromised and act quickly:

Disconnect the machine from the network before doing anything else.
Assume every password saved in any Chromium-based browser is stolen. Rotate all of them.
Move funds out of any wallet whose seed phrase or keystore was anywhere on that machine, and treat those seeds as burned.
Rotate SSH keys, cloud API keys, and every secret in every .env on the machine.
Rotate anything that was in your clipboard during the exposure window (it watches the clipboard continuously, which is enough to catch a pasted wallet address).
If you use WSL, treat the entire Windows host as in scope, not just the Linux side. This malware pivots from WSL into C: drive user folders.

If in any doubt, get help from someone who does incident response. Rotating credentials is cheap. Regret is not.

The takeaways

A safe npm install does not mean a safe build. Supply-chain awareness fixates on install hooks. This attack ignores them and uses ordinary build configuration, which is just executable code with no sandbox.
Read the config files, not only the source. That is where untrusted code gets to run.
Compare file sizes. One outlier was the entire tell.
Treat pre-emptive "this is safe" comments as signals, not comfort.
Your AI agent can be the attack vector. If you delegate "have a look at this repo" to an agent that can execute commands, you have handed untrusted code a way to run. Sandbox it, or explicitly tell the agent to treat the repo as hostile and never build or run it.
When you evaluate anything untrusted, do it in a throwaway virtual machine or container. Isolation is what saved me. Note that a bind-mounted folder still exposes that folder, so isolation is a spectrum, not a switch.

The friendly job offer, the working app, the detailed roadmap and the busy commit history all exist for one reason: to earn the few seconds of trust between "run it" and execution. Do not give it to a stranger.

Indicators of compromise (safe to share): repo BitAngelsLabs/auron; malicious file theme/js/auron-core.min.js at 4,073,468 bytes; C2 at 153.75.87.26 on ports 8085, 8086 (/upload), 8087; runtime install of sql.js, socket.io-client, node-pty via --no-save; background process node --max-old-space-size=4096 --no-warnings -. If you found this repo, report it to GitHub as malware and warn anyone who may have cloned it. The malicious file itself should not be shared or re-hosted.

DEV Community: pycanis