Fake Trading Bot Scams: Lazarus's New GitHub Playbook

You see an open-source “MEV front-runner” on GitHub. Clean README, months of commits, real-looking issues. Cloning, installing, running once is a routine developer move — safe by default. But since 2026, attacks on crypto developers parked themselves exactly at that moment: you think you are testing code, the other side thinks you are handing over a wallet. One repeat-mentioned source is the North Korean group Lazarus.

The point is not which repo is fake — they swap names like clothes. The point is how the project itself is weaponized: malicious code in dependencies, build scripts, or helpers — so one npm install, python main.py, or IDE auto-load drops your machine into remote control, then they wait for a real key. Same patience as the $284M Trezor phishing wave: the actor is people, not vulnerabilities.

Not the same as “fake wallet apps”

People lump this with fake wallet apps and extensions, but the audiences differ. Fake wallets phish regular users who saw an ad. Fake trading bots phish developers who arrive on GitHub with technical confidence. The latter is harder to defend because “I read code” already weakens the defense.

Worse: attackers wrap themselves in real-project shells — fork a real repo and edit a few lines, or build a fresh repo that mimics a real layout, license file, and CI config. The page alone barely looks off.

Where the payload hides

Favorite hiding spots:

• Malicious dependencies: a package.json or requirements.txt entry is a typosquat pulled in silently on install.
• Build scripts: postinstall, scripts, or Makefile sneaks in a fetch-and-run line. Few read npm install output line by line.
• Config loaders: a “convenience” .env.example references a utility library that contains a backdoor.
• Private-key intake: bots need a key. Docs explain how to drop it into an env var — the moment you do, telemetry exfiltrates it.
• IDE auto-execute: a .vscode/tasks.json triggers a “health check” on open — which is remote control.

Common thread: they do not steal old files; they wait for you to put new things in.

A typical script

Compressed:

You get @-ed in a respectable “quant trading” Discord or Telegram group. The person is working on an MEV front-runner that “consistently does 5–8% monthly in private testing.” They drop a GitHub link — complete project layout, researcher-style README, a “whitelist only” note that signals ops seriousness.

You fork. pip install runs green. The doc says fill in an RPC and signing key in .env (“just a clean wallet is fine”). You hesitate, then create a fresh wallet, fund it with 0.1 ETH. The bot starts. Console prints a couple of lines. Normal.

What happens next ranges from two hours to two weeks. Fast path: the script ships the key on first launch and drains it. Slow path: it behaves normally, you “scale up the principal,” and only at a balance threshold does the drain trigger.

The so-called bot may not be doing arbitrage at all. Its real job is convincing you to willingly feed a key and funds into a process the other side controls.

A checklist you can run today

Turn the following into a fixed pre-clone routine:

1. Never run an unknown repo on the host. Third-party projects go straight into a VM or one-shot container for untrusted code, with no main-wallet files. This single rule blocks most attack volume.
2. Audit the dependency list by hand. For unfamiliar packages, check registration date, download count, maintainer history. “Created last week, single maintainer, only 1.0.0” — default suspicious.
3. Read build scripts first. postinstall, prepare, scripts.start are the favorite hideouts. Any Makefile with curl ... | sh is refuse-to-run.
4. Never put your main-wallet key into a bot. Even for tests, generate a brand-new, isolated burner. Same logic as basic crypto security habits.
5. Projects asking for your seed phrase to “recover the strategy” close immediately — same line as fake support scam.
6. Doubt the yield narrative. “5–8% monthly consistently” is mythological in classical quant. A stranger DM is phishing by default.

“Open source = auditable” has a condition

“Open source is safe” originally meant “anyone can audit,” not “someone has audited.” Lazarus rides on this cognitive slip: on GitHub, a few hundred stars, polished README, dev community defaults to “should be fine” while no one has read it line by line.

The stable stance: unread code = untrusted code. Any project asking you to “plug in a key immediately” defaults to “not on mainnet until every dependency and build script is read.”

Even a developer’s notion of “safe” can be fooled

Technical confidence is a developer’s main resource — and the main hole in this kind of attack. Experienced people do not think “I read code, so I am safe.” They admit: the more code you have read, the more you know how much malice fits in a few lines. Lazarus-style scams do not crack cryptography or kernel security. They ride on your moment of “trying it should be fine.” Delete that sentence, pair with a disposable VM and a one-shot test wallet, add the social-engineering reflexes from spotting crypto scam emails and SMS — and this class of attack stops reaching the main wallet. Short to-do list, but each line must be executed seriously.

Educational, not investment advice. Operate together with your device, platform, and official documentation.