farezv.com (@farezv) on X

Developer recruitment scams have evolved from simple phishing emails to sophisticated multi-layer social engineering attacks that exploit trust at every level:

• Layer 1 - Social Engineering: Fake LinkedIn profiles impersonating recruiters from legitimate companies

• Layer 2 - Urgency Creation: "Review this code before our technical call tomorrow"

• Layer 3 - Borrowed Credibility: GitHub repositories with spoofed commits from well-known developers

• Layer 4 - Malware Delivery: Hidden backdoors in seemingly legitimate code that execute on npm install

My Two Close Calls: A Case Study in Escalating Sophistication

Incident #1: The Racing Legends Scam (August 2025)

A "recruiter" claiming to be a Partner from a popular Web3 company @Chainlink contacted me via @Linkedin, asking me to review their "Racing Legends" staking platform before a technical interview. Red flags immediately appeared:

• LinkedIn Profile Inconsistencies: This is a profile I have no connections with. I've been to enough crypto conferences over the past 4-5 years so usually have someone in common), generic job description. After I recognized the backdoor issue, I did a reverse Google Image Search.

Instead of running `npm install && npm run dev` as requested, I asked Claude Code to analyze the repository. @ClaudeAI immediately detected malicious backdoor code in `server/middlewares/validator/errorHandler.js` and refused to continue analysis due to policy violations.

I decided to get on a call the next day anyways and a guy called "Ahmed" with an accent I didn't recognize fully with broken English insisted he couldn't screen share due to being on mobile but wanted me to run this code on our call which I gently refused to do. He ended the call after a few minutes, likely recognizing that I won't fall for the scam.

I reported this to Chainlink's CISO on Linkedin, however I never heard back and since then, Mike Hartley's Linkedin profile and the Racing Legends Github repo have disappeared with those respective links hitting 404s.

Incident #2: The Spoofed Commit Attack (September 2025)

Just yesterday, another "Web3 founder" messaged me with a similar request. This time, the repository appeared more legitimate - it contained commits from Nader Dabit, a well-known developer in the Web3 ecosystem.

However, I happen to know @dabit3 personally and knew he wouldn't be moonlighting on random projects considering he works at @eigenlayer (& I interviewed there earlier this year).

https://github.com/chain333/coin-promoting/commits/main/ is the repo. WARNING: Please do not download or run the code here. @github should probably flag this internally and remove it.

My friend Mike Yu (https://www.linkedin.com/in/mikeyyy/) helped verify my suspicion by demonstrating how trivially commits can be spoofed:

git clone https://github.com/dabit3/devkit-oracle
git config --global user.name "nader dabit"
git config --global user.email "[email protected]"
# Make changes, commit, and push

The result: commits that appear to be from Nader but are completely fabricated - https://github.com/yuyuma/devkit-oracle/commits/main/. Please note, this is a good test repo Mike put together.

The Technical Reality: Why Git's Decentralized Nature Enables This Attack

As my other friend Michal Przadka explained, Git's decentralized architecture - ironically similar to blockchains - means there's no central authority verifying commit authenticity. GitHub displays committer details from the git history, but these can be trivially spoofed because:

1. Most developers don't sign their commits with GPG keys
2. Git allows arbitrary user.name and user.email configuration
3. GitHub's UI doesn't prominently distinguish between verified and unverified commits. I know the distinction is there, but it's easy to miss when "borrowed credibility" is involved.
4. Developers trust Github pretty easily if at first glance a well known developer has committed to it

What These Attacks Target

Had I run npm install on either repository, the malicious code could have:

• Harvested SSH Keys: ~/.ssh/ contains keys for server access and GitHub authentication
• Stolen Web3 Credentials: Private keys, seed phrases, wallet files
• Exfiltrated API Secrets: Environment variables, .env files, AWS credentials
• Installed Persistent Backdoors: Launch Agents/Daemons that survive system restarts
• Scanned Development Projects: Proprietary code, database credentials, client secrets

How I Verified My System Remained Clean

After the first incident in August (I never cloned yesterday's repo), I ran comprehensive security checks without executing any repository code:

1. Command History Verification:tail -n 100 ~/.zsh_history
   # Confirmed no npm install or node commands were run
2. Process Inspection: ps aux | grep -E 'node|npm|git'
   lsof -i -P | grep ESTABLISHED
3. Persistence Mechanism Checks: crontab -l
   ls -la ~/Library/LaunchAgents/
   ls -la /Library/LaunchDaemons/
4. File System Verification: find ~ -type f -mtime -1 -not -path "*/Library/*"
   stat ~/.ssh/id_*

All checks confirmed no malicious code had executed or persisted on my system.

The Uncomfortable Truth About macOS Security

Neither FileVault (disk encryption) nor Gatekeeper (app verification) protect against malicious Node.js code. Once you run npm install:

1. The code executes with YOUR full user permissions
2. It can read all your files (with limited exceptions for Desktop/Documents)
3. It bypasses Gatekeeper because the node binary is already approved
4. FileVault only protects data at rest, not from running processes

Protecting Yourself: A Developer's Security Checklist

1. Never run code directly on your host machine from unknown sources
2. Use virtual machines or containers for all technical assessments
3. Verify recruiter legitimacy through multiple channels
4. Check for verified commits (look for the "Verified" badge on GitHub)
5. Review package.json scripts before running npm install
6. Enable commit signing on your own repositories
7. Question unusual requests - legitimate companies use sandboxed coding platforms

The Broader Implications

This attack pattern reveals critical vulnerabilities in our development ecosystem:

• Trust assumptions - We assume commits from familiar names are legitimate
• Convenience over security - Running code locally is easier than setting up VMs
• Social engineering effectiveness - Technical sophistication doesn't protect against psychological manipulation

Call to Action

The developer community needs to:

1. Advocate for GitHub to make commit verification status more prominent
2. Normalize GPG signing for all commits
3. Share these attack patterns widely to prevent others from falling victim
4. Push legitimate companies to use sandboxed platforms for technical assessments

Remember: That repository asking you to "just run npm install" might be one command away from compromising your entire digital identity. When in doubt, don't run it locally - your SSH keys, cryptocurrency wallets, and client credentials depend on it.

I'm going to dive deeper into how LLMs can detect malicious code and how we can build system prompts (maybe?) that can be used with local models such as DeepSeek, Kimi K2 & others to build secure developer workflows. Thanks you for reading.