The Evolution of Developer-Targeted Recruitment Scams: From Fake Profiles to Spoofed Commits

security developers recruitment scams social-engineering github npm malware cybersecurity git
January 27, 2025
5 min read
By Farez Vadsaria

Table of Contents

This is a list of all the sections in this post. Click on any of them to jump to that section.

The Evolution of Developer-Targeted Recruitment Scams: From Fake Profiles to Spoofed Commits

The Attack Vector Evolution

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” from a Web3 company contacted me via LinkedIn, asking me to review their “Racing Legends” staking platform before a technical interview. Red flags immediately appeared:

• LinkedIn Profile Inconsistencies: Recent profile creation, generic job description, limited connections • Unusual Request Pattern: Download and run code locally rather than reviewing on GitHub • Repository Anomalies: No meaningful commit history, suspicious file structures

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

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

Just weeks later, another “Web3 recruiter” approached me with a similar request. This time, the repository appeared more legitimate - it contained commits from Nader Dabit, a well-known developer at Eigen Layer.

However, I happen to know Nader personally and knew he wouldn’t be moonlighting on random projects. My friend Mike Yu 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.

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

As my 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

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 that survive system restarts • Scanned Development Projects: Proprietary code, database credentials, client secrets

How I Verified My System Remained Clean

After each incident, 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:

• The code executes with YOUR full user permissions • It can read all your files (with limited exceptions for Desktop/Documents) • It bypasses Gatekeeper because the node binary is already approved • 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.

Special thanks to Mike Yu and Michal Przadka for their technical insights on Git’s architecture and commit spoofing demonstrations.