The Fake Job Interview Attack

This attack targets people who work in crypto rather than people who hold it, and it has been responsible for some of the largest protocol compromises on record.

The sequence

Contact. A recruiter approaches through a professional network or directly. The role is plausible, well-paid, and relevant to the target’s actual skills.

Conversation. Several exchanges over days or weeks. The recruiter is professional, the company has a website and a history, and everything checks out at a casual level.

The assessment. The target is asked to complete a technical exercise. They are sent a repository to clone and run, or a document to open, or asked to debug a piece of code.

The compromise. Running the code executes malware. It harvests browser credentials, wallet files, session tokens and, in targeted cases, deployment keys.

The use. Depending on the target, the access is used to drain personal wallets or to reach the infrastructure of the project they work on.

Why it works so well

It exploits a professional context. Running unfamiliar code is a normal part of a technical assessment. The request is exactly what a legitimate process would involve.

The targets are technical. People who would never click a phishing link will clone a repository, because that is their job.

It is patient. Weeks of ordinary conversation before anything is asked.

The company exists. Some campaigns use real companies whose names are being impersonated. The target verifies the company and finds it real.

The defences

Never run assessment code on a machine that holds anything. A dedicated virtual machine or a separate device, with no wallets, no credentials and no access to anything that matters.

This single measure defeats the entire attack.

Verify the recruiter independently. Contact the company through its own published channels rather than through the person who approached you. A real recruiter survives this; a fake one does not.

Be suspicious of urgency in a hiring process. Legitimate processes tolerate a day’s delay.

Treat documents with the same caution as code. Several campaigns have used documents with embedded execution rather than repositories.

For organisations

The same attack aimed at a team member with deployment access is how several protocol compromises have occurred. The lesson at an organisational level is that a single compromised developer should not be sufficient to move funds or deploy contracts.

Multi-signature requirements with geographically separated signers, and timelocks on upgrades, convert an individual compromise into an inconvenience rather than a catastrophe.

For individuals not in the industry

The direct relevance is limited and the principle transfers: never run unfamiliar code on a device that holds keys.

The broader version is the same conclusion this site keeps reaching. Keep the working balance somewhere a compromised device cannot reach it, such as an exchange you can actually contact with a withdrawal allowlist, and keep long-term holdings on a device that does nothing else.