Fake Recruiters, Malicious Repos, and the Need for Recruiter Verification
# Fake Recruiters, Malicious Repos, and the Need for Recruiter Verification
I am getting a few fake recruiters every day now.
The pattern is almost always the same: someone contacts me about a developer role, usually involving blockchain, Web3, AI, backend engineering, or infrastructure. The pitch sounds urgent but plausible. Then they ask me to clone a GitHub repository and run it on my machine.
That request is the red line.
A legitimate recruiter may send a job description, company page, interview link, or take-home assignment. But when an anonymous recruiter asks a developer to execute unknown code locally, that is no longer just a hiring conversation. That becomes an operational security problem.
Many of these recruiters hide behind Telegram, Signal, anonymous email addresses, fake profiles, and vague company names. There is no real visibility into who they are. No verifiable company identity. No clear hiring manager. No traceable business footprint. No normal recruiting process.
That is why I started treating recruiter legitimacy as something that must be verified, not assumed.
## Why Fake Recruiters Target Developers
Developers are valuable targets because they have access to machines, credentials, private repositories, cloud environments, SSH keys, API tokens, crypto wallets, browser sessions, and production systems.
A malicious “technical assessment” can be used to trick a developer into running code that steals secrets, opens a reverse shell, scans the local machine, exfiltrates environment variables, or compromises browser profiles.
The repo may look normal. It may even have a working app. But malicious behavior can hide in install scripts, package dependencies, postinstall hooks, Docker files, Makefiles, binaries, obfuscated JavaScript, build steps, or test runners.
The scam does not need to be sophisticated if the target simply runs the code on their personal or work machine.
## My First Response: Build a Quarantine
Initially, I decided to build a quarantine environment for suspicious repositories.
The goal was simple: never run unknown recruiter code directly on my main machine.
A quarantine setup can include isolated virtual machines, disposable containers, locked-down networking, no mounted secrets, no browser profiles, no SSH keys, no cloud credentials, no wallet files, and no access to personal directories.
That tool is still useful. But the problem turned out to be bigger than just “how do I safely run this repo?”
The better question became:
Should I even be talking to this person at all?
## The Bigger Problem: Anonymous Recruiters Are Not Verifiable
The more fake recruiters I saw, the clearer the pattern became.
Legitimate people leave traces.
Scammers usually do not.
A real recruiter, founder, hiring manager, or company should usually have some combination of these signals:
- A real company domain
- A normal business email address
- A consistent LinkedIn footprint
- Public company records
- Real employees
- Press, product, funding, or customer history
- A verifiable website
- A hiring page
- A clear relationship to the role
- Normal interview logistics
- A willingness to do a video call
- A written process that names the company and legal entity
Scammers usually push the opposite direction:
- Telegram or Signal only
- Anonymous handles
- No company email
- No video call
- No verifiable identity
- Urgency
- Vague role details
- Repo-first interview process
- Requests to run code before basic legitimacy is established
That contrast became the driving force behind my website redo and the development of open-source intelligence tools.
## The Principle: Legit People Are Verifiable
The main idea is simple:
Legit people are verifiable. Scammers are not.
That does not mean every legitimate person has a huge public profile. Some good people have a small footprint. Some early-stage startups are quiet. Some recruiters work through agencies.
But there should still be enough evidence to connect the person, the company, and the opportunity.
When someone claims to represent a company, I want to verify that claim independently. Not from screenshots. Not from documents they send me. Not from their own words. I want external signals.
That means checking whether the person exists outside the chat window.
## The Tool I Built Around This
I now keep a set of tools and workflows for checking suspicious recruiters, companies, and online identities.
One of the places I am documenting that process is here:
[Tools for checking suspicious recruiters and online legitimacy](How to Use the Pigfox OSINT Tools — Beginner's Guide)
The purpose is to help evaluate whether a recruiter, founder, company, or project has a real footprint on the web.
The goal is not to “prove fraud” from one weak signal. The goal is to separate claims from independently verifiable facts.
## What I Check Before Trusting a Recruiter
Before I clone anything, run anything, or send anything sensitive, I want answers to basic questions:
- Who is this person?
- What company do they represent?
- Does their email match the company domain?
- Does the company have a real website?
- Does the job exist on the company website?
- Is the recruiter connected to the company on LinkedIn?
- Do other employees appear to be real?
- Is there a normal interview process?
- Can the recruiter do a video call?
- Can the hiring manager be verified?
- Does the company have public records, product history, customers, funding, GitHub activity, or other independent signals?
If the answer to most of these is “no,” I treat the opportunity as high risk.
## Red Flags in Fake Developer Recruiting
These are the patterns that make me pause immediately:
- Recruiter only uses Telegram, Signal, WhatsApp, or Discord: Anonymous channels make identity difficult to verify.
- No company-domain email: Real recruiters usually have traceable business contact details.
- Repo must be cloned before any real interview: This can be a malware delivery path.
- Urgent technical test: Urgency reduces verification time.
- Vague company or stealth project: It becomes hard to verify who is actually hiring.
- No video call: This prevents basic identity confirmation.
- No job posting on the company website: The role may not exist.
- Compensation sounds unusually high: Big numbers can be used to override caution.
- GitHub repo has strange install steps: Malware often hides in setup scripts.
- Recruiter resists verification: Legitimate recruiters usually understand basic caution.
The biggest red flag is not one single thing. It is the combination of anonymity, urgency, and a request to run code.
## Why “Just Use Docker” Is Not Enough
Some people say, “Just run it in Docker.”
That is better than running code directly on the host, but it is not a complete answer.
Docker can still expose risk if the setup mounts local folders, accesses the network, uses privileged mode, reads environment variables, runs malicious dependency scripts, or tricks the developer into copying secrets into the environment.
A safe quarantine has to assume the repo is hostile.
That means:
- No host secrets
- No mounted home directory
- No SSH keys
- No cloud credentials
- No browser cookies
- No crypto wallets
- No production database access
- No privileged containers
- No shared clipboard for secrets
- No blind execution of install scripts
The safest approach is to verify the recruiter first, then inspect the repo, then decide whether it is worth running at all.
## A Simple Recruiter Risk Score
I use a practical scoring mindset.
Add risk when:
- Identity is unclear: +15
- Company connection is unverified: +20
- Communication is only through anonymous chat: +10
- They ask me to clone and run code early: +25
- They refuse video or company email verification: +20
- The job is not listed anywhere official: +15
- They pressure me to move fast: +10
Reduce risk when:
- Company-domain email is verified: -15
- Job exists on official company site: -15
- Recruiter is listed or connected to the company: -15
- Hiring manager is verifiable: -15
- Normal interview process exists: -10
- Written contract or formal process is provided: -10
If the score is high, I do not run code, provide documents, connect wallets, share credentials, or continue the process without stronger proof.
## What Developers Should Not Do
Until the recruiter and company are verified, do not:
- Run unknown code locally
- Install dependencies from an unfamiliar repo
- Run shell scripts from a recruiter
- Share passport, tax, banking, or payroll details
- Connect a crypto wallet
- Send private GitHub access
- Share production credentials
- Use your work machine
- Open files that require macros or unusual permissions
- Accept payment through checks, crypto, or strange intermediaries
- Continue only through anonymous chat channels
The burden of proof should be on the recruiter, not on the developer.
## What a Legitimate Recruiter Should Be Able to Provide
A legitimate recruiter should usually be able to provide:
- Their full name
- Company name
- Company-domain email
- Job description
- Official job posting
- LinkedIn profile
- Hiring manager identity
- Interview process
- Video call option
- Written agreement before sensitive information is requested
For early-stage startups, the footprint may be smaller. But even then, the founder, company, repo, funding history, product, or business registration should be verifiable in some way.
## The Main Lesson
The old assumption was:
If the job sounds good, take the call.
The new assumption is:
If the person is anonymous and wants me to run code, verify first.
That is especially true in Web3, crypto, AI, and backend infrastructure, where developers often have access to valuable systems and credentials.
Fake recruiters are not just wasting time. They can be an attack vector.
That is why I rebuilt my process around open-source intelligence, recruiter verification, and quarantine tooling.
The rule is simple:
Do not run the repo until you know who is asking.