Fake job offers: when the interview is the attack

·5 min read·By SSP Editorial Team
SSP Academy cover: fake job offer malware

Fake job offers: when the interview is the attack

A recruiter messages you about a well-paid role at a crypto company. The conversation is professional, the company looks real, and the next step is a short technical task: clone a repository, install the dependencies, run it and fix a bug. Or perhaps a video call, where the interviewer asks you to install a meeting app or a "camera fix" first.

For a growing number of people, that was the moment their machine — and their crypto — was compromised. Fake hiring is now one of the most effective ways to put malware on exactly the computers attackers want: those belonging to developers, traders and people who work in crypto.

How the scheme works

The pattern varies, but the core is consistent:

  1. A believable approach. A message on a professional network, a job board or a chat app, from a recruiter or founder with a polished profile — sometimes impersonating a real company, sometimes inventing a plausible one.
  2. A normal-looking process. A screening chat, a role description, salary discussion. Nothing alarming, and often days of it, to build trust.
  3. The payload step. You're asked to run something: a coding test from a repository, a project to review, a meeting app from a link they send, or a script to "fix" a webcam or audio problem on a call.
  4. Quiet theft. The code installs malware that searches for wallet extensions, browser-stored passwords, recovery phrases in files and notes, and session cookies — then sends them out. Funds can disappear the same day or weeks later.

What makes it effective is that running unfamiliar code is a completely normal part of a technical interview. The request doesn't feel strange, because usually it isn't.

Where the malicious part hides

In the take-home variant, the obvious code is often clean. The payload sits somewhere you're unlikely to read:

  • Dependencies. A package in the project's dependency list that runs code when it's installed.
  • Install and build scripts. Hooks that execute automatically when you install or start the project.
  • Obfuscated configuration. A long, unreadable string in a config file that's decoded and executed at runtime.
  • "Required" tools. A custom CLI, browser extension or meeting client you're told the task needs.

You can review every line of the task itself and still be infected the moment you install.

Red flags

None of these proves a scam alone, but together they should slow you right down:

  • Urgency around the technical step — "please complete it today", "the hiring manager is waiting".
  • Running code is required before any meaningful conversation about the role, team or contract.
  • Unusual software for a call — a meeting app you've never heard of, or a "fix" script for a camera or microphone.
  • Mismatched details — a company domain that doesn't match the recruiter's email, a website registered recently, or a team page with no verifiable people.
  • Pressure to use your main machine, or annoyance when you suggest a sandbox.
  • Pay that's notably above the market for a role with a vague description.

How to protect yourself

  • Never run interview code on a machine that holds crypto. Use a separate computer, a virtual machine or a disposable cloud environment with nothing valuable in it.
  • Install nothing a stranger links you to for a call. Mainstream meeting platforms run in the browser; you don't need a special client.
  • Verify the company independently. Find its official site and careers page yourself and confirm the role and the recruiter exist.
  • Keep secrets off general-purpose machines. Recovery phrases don't belong in files, notes, screenshots or password managers on the computer you use for everything else.
  • Treat a compromised machine as compromised. If you ran something suspicious, assume whatever was accessible on that computer is exposed.

These are part of the same discipline as a good opsec checklist: reduce what a single compromised device can reach.

Where two devices help

This is exactly the scenario SSP's 2-of-2 design is built for. Malware on your computer can reach SSP Wallet's key on that computer — but it can't spend on its own, because every transaction also needs approval on SSP Key, on your phone. A stolen browser key alone moves nothing.

The protection isn't unconditional. If the same malware also finds your SSP Key recovery phrase — saved in a note, a screenshot or a file on that computer — the attacker has both keys. Keeping the two recovery phrases off the computer, and apart from each other, is what keeps the second key meaningful.

And if your computer was compromised, don't wait to find out whether anything was taken. What to do when one key is compromised walks through moving funds to fresh keys while the second device still protects them.

If you think you ran something malicious

  1. Disconnect the machine and stop using it for anything sensitive.
  2. From a clean device, move funds from any wallet whose keys or recovery phrase were on that computer.
  3. Change passwords and revoke sessions for email, exchanges and work accounts, starting with email.
  4. Report the profile and messages to the platform where the contact started — and, if they impersonated a real company, to that company.
  5. Rebuild the machine before trusting it again.

The honest summary

Fake job offers work because they turn a normal professional step — running someone's code — into the attack. The code you're asked to review may be clean; the dependency, script or meeting app around it may not be.

Keep interview work on a machine with nothing to lose, install nothing a stranger links you to, and keep your recovery phrases off the computer entirely. With a second device approving every transaction, one compromised computer becomes a problem to clean up rather than a loss.

Share this article

Related articles