I Almost Got Scammed by a Fake Job Offer - Here's What Happened

Job scams are no longer the poorly spelled emails from a Nigerian prince. In 2026, they arrive as polished LinkedIn messages from someone with a professional headshot, a credible job title, and knowledge of your actual work history. They include video calls, structured interviews, and realistic technical assessments.

This is what happened when one of those scams targeted me, and what I found when I looked closer at what it was actually designed to do.

How It Started: A Message That Looked Completely Legitimate

The recruiter's message referenced real companies and specific skills. The tone was professional and the role, a blockchain project management position was relevant. Nothing felt off.

A call was scheduled. During the conversation, the recruiter asked sensible interview questions, discussed the team structure, and quoted a competitive salary range. The company was real. The industry terminology was accurate. Everything followed the expected rhythm of a first-round interview.

Then came the "technical assessment": a repository link and an instruction to run the code, share thoughts on the architecture, and report back within a day or two.

This is where the scam begins: not with something obviously suspicious, but with something that feels completely routine.

The Warning Signs That Are Easy to Miss

Looking back, several indicators were present from the first message. They are easy to overlook because scammers have specifically designed each stage to feel normal. Understanding them in advance is the only reliable defense.

1. The Email Address Contained Numbers

The recruiter used a Gmail address with a number appended to what appeared to be a real person's name; for example, johnsmith214@gmail.com rather than johnsmith@company.com.

This is the single most reliable early indicator. Recruiters at genuine companies use company email addresses. A Gmail account with numbers appended to a real-sounding name is the most consistent fingerprint across documented recruitment scam campaigns.

In this case, the real professional whose identity had been stolen later confirmed the impersonation. The scammers had copied their name, photo, LinkedIn profile content, and professional history.

2. The Video Call Was Refused

The interview was conducted voice-only. When video was requested, the recruiter cited "camera issues." This is a deliberate choice, not a technical accident.

Scammers cannot appear on camera because their face does not match the stolen professional identity they are impersonating. Refusing video is a structural requirement of the scam, which is why it appears consistently across nearly all documented cases in this category.

In 2026, there is almost no legitimate reason for a professional recruiter to refuse a video call. Any recruiter who consistently deflects video, across multiple attempts and platform suggestions should be treated as a serious red flag.

3. There Was Pressure to Move Quickly

Throughout the process, there were references to "other candidates in the pipeline" and urgency around timelines. This is a social engineering technique with a specific purpose: it activates a fear-of-missing-out response that discourages the careful verification a candidate would otherwise perform.

Legitimate employers accommodate reasonable requests for time. Scammers cannot afford to - delay gives the target time to check the email address, verify the identity, or ask a trusted colleague.

4. The Repository Was Brand New

The code repository sent as the "technical task" had been created less than two weeks before it was shared. It had only three commits, one contributor, no issues, and no pull request history. A genuine company's codebase, even a sample project, does not look like this.

What the "Technical Task" Was Actually Designed to Do

The repository appeared to contain a legitimate Node.js web application, the kind a developer might plausibly be asked to review. The first part of the main file looked completely normal. The malicious component was hidden several hundred lines further into a secondary file, disguised as an error handling utility.

What the code was designed to steal:

• SSH keys: The credentials used to access servers and remote infrastructure
• AWS, Google Cloud, and Azure access credentials: Cloud platform keys that control billing and data
• Cryptocurrency wallet files: Direct access to wallet balances
• Browser session data and saved passwords, including banking and email sessions
• API keys and database passwords, stored in configuration files on the developer's machine
• Git and NPM tokens, used to access and modify code repositories

The theft would happen silently, in the background, while the application appeared to run normally. There would be no error message, no alert, and no visible sign that anything had gone wrong. The data would be transmitted to attacker-controlled servers before the developer had finished reviewing the code.

There was also a second layer to the attack. The "task" expected the developer to push their solution to their own GitHub profile and share the link. Code hosted under a legitimate developer's account is trusted by other developers, evades automated security tools, and can be shared with future victims. The scammers were, in effect, trying to use the target to distribute their malware.

Why Developers Are a Specific Target

This type of scam disproportionately targets software developers, and particularly those working in blockchain and fintech. The reasons are structural:

• Developers have access to production infrastructure - servers, databases, cloud platforms, and code repositories that can have serious downstream consequences if compromised.
• Running code as part of a hiring process is completely normal. Developers complete technical assessments dozens of times in their careers. The scam exploits this expectation directly.
• Blockchain and Web3 developers often hold significant cryptocurrency, which can be stolen instantly and irreversibly.
• Remote-first work culture makes voice-only calls and entirely digital interview processes feel unremarkable.
• Technical confidence can create a false sense of security - the assumption that "I would spot malware" is precisely what the scammers are counting on.

Scam campaigns in this space are not improvised. They involve researching targets in advance, constructing credible personas, building functional fake websites with valid HTTPS certificates, and cloning real professionals' identities in detail. This is organized criminal infrastructure, not opportunistic fraud.

The Scale of the Problem

This is not an isolated pattern. The data on how widespread and damaging these scams have become is stark.

The psychological impact of these scams extends well beyond financial loss. Victims often delay reporting because of shame. Many do not realize they have been compromised until unauthorized cloud charges appear weeks later, or a service they use sends a breach notification.

What Actually Prevented the Compromise

Three things stopped this attack from becoming a serious incident:

• The code was run on an isolated cloud server rather than a personal development machine. A clean environment with no stored credentials meant there was nothing for the payload to steal. This single decision is the most important protective measure any developer can take.
• While investigating one of the websites involved, checking the browser developer console revealed that a password was being captured and transmitted in plaintext. This is definitive evidence of credential harvesting infrastructure built into the site.
• The numeric suffix in the recruiter's email address was noticed before any further information was shared, prompting direct contact with the real professional whose identity had been stolen - who confirmed the impersonation.

It is worth being direct: some of this was luck. Not every target will catch these details in time. The wallet involved was empty, which prevented asset loss from one of the other attack vectors. The protective measure that can be reliably applied regardless of luck is sand-boxed execution.

What Happens After a Compromise

Understanding what attackers do with stolen credentials explains why acting quickly matters so much. When SSH keys, cloud credentials, and API tokens are exfiltrated, the attacker gains access to a range of secondary targets:

• SSH keys can be used to log into servers that the developer has access to - including employer infrastructure, client systems, and production databases.
• AWS and cloud credentials can be used to spin up compute resources for cryptocurrency mining, which bills to the victim's account, to exfiltrate stored data, or to access connected services.
• API tokens give access to GitHub and GitLab repositories, which may contain proprietary code, additional credentials embedded in configuration files, or access to downstream services.
• Browser session data allows attackers to access email accounts, banking services, and any platform where a session was active - without needing the password.
• Cryptocurrency wallets, once accessed, are emptied immediately. Blockchain transactions are irreversible.

Sophisticated attackers also install persistence mechanisms - scheduled tasks or modified SSH configuration, so that they retain access even after the developer changes their passwords and believes the incident is resolved.

How to Protect Yourself: A Practical Guide

Before Engaging with Any Recruiter

• Check whether the recruiter's email address appears on their LinkedIn profile. If it does not match, that is a significant indicator.
• Verify that the domain is the company's actual corporate domain - not Gmail, Outlook, Protonmail, or Yahoo.
• Search the recruiter's name combined with the company name on Google to confirm they exist in that role.
• Visit the company's official careers page directly to confirm the role is listed. Do not rely on links sent in the initial message.
• If the message feels unusually flattering or improbably well-timed, treat that as a signal to verify more carefully, not less.

During the Interview

• Require a video call. Do not proceed without one, regardless of the excuse offered. This is the single most effective verification step available.
• Ask for the LinkedIn profile of the person you would be reporting to, and verify it independently.
• If you are directed to a website as part of the process, open the browser developer console and watch the network tab for unexpected requests.
• Never connect a cryptocurrency wallet to a website you were directed to during a recruitment process.
• Never enter account passwords into sites you were sent by a recruiter.
• If you feel pushed to decide quickly, name a specific extension - "I need three more days" - and observe the response. Legitimate employers accommodate this. Scammers push harder.

When You Receive Code to Review or Run

• Never run provided code on your personal development machine. This is the most important rule, and the most commonly broken one.
• Use a clean, isolated environment: a disposable cloud instance, a Docker container, or a virtual machine.
• Review the entire repository before running anything, not just the files that seem relevant to the task.
• Check the repository age and commit history. A "production" codebase with two commits created two weeks ago is not a production codebase.
• Look for files that seem out of scope for the stated task: payment handlers, error utilities with unusual length, or configuration files referencing external URLs.

If You Think You May Have Already Run Suspicious Code

If code from an interview task has already been executed on a personal machine, the priority is to act quickly. The exfiltration typically happens within seconds of execution.

Immediate Steps

• Disconnect the machine from the internet as soon as possible to stop any ongoing data transmission.
• Do not continue using the machine until it has been assessed.

Within 24 Hours — Credential Rotation

• Change SSH keys and update the authorized keys on all servers you have access to.
• Rotate cloud platform credentials via the web console - do not use the command line on the potentially compromised machine.
• Revoke all GitHub and GitLab personal access tokens and reissue them with minimal required permissions.
• Change passwords for any accounts where credentials may have been stored or recently used.
• Enable two-factor authentication on email and critical service accounts if not already active.

Ongoing Monitoring

• Enable billing alerts on cloud platforms to catch unexpected charges - these sometimes appear days or weeks after the initial compromise.
• Check cryptocurrency wallet balances immediately and monitor them closely.
• Review recent activity logs on GitHub, AWS CloudTrail, and Google Cloud to identify any access from unrecognized IP addresses.
• Notify your employer's security team if you have access to company infrastructure that may have been reachable via stored credentials.

A Community Response to a Community Problem

After this experience, and after connecting with others who had encountered identical patterns, a clear gap became apparent: there was no central place to check whether a recruiter, repository, or domain had been flagged before.

The fragmentation of this information, spread across LinkedIn comments, Reddit threads, and informal developer group chats, means that the same scam infrastructure gets reused against new victims for months. One person's report rarely reaches the next target in time.

This led to the development of RTIDX (Recruitment Threat Index) - a community-powered platform where developers can submit suspicious recruiter interactions and receive a risk assessment based on automated pattern analysis and shared community intelligence. Submissions are anonymized, verdicts are transparent, and the goal is to make threat information available before someone clicks, runs, or shares - not after.

rtidx.com

Want to Understand the Attack Itself?

This post focused on what happened, why it works, and how to protect yourself. But the code inside that repository was doing something technically specific - and understanding exactly how it works is what makes the pattern truly recognizable.

In a companion post, we break down the complete attack chain from a technical perspective: how the malicious payload was structured to evade casual code review, the exact JavaScript technique used to achieve silent remote code execution, how the exfiltration was routed to avoid detection, and what the repository's secondary objective revealed about how scam infrastructure gets distributed at scale.

If you are a developer, a security engineer, or someone responsible for a team that handles technical interview processes, that post covers the actionable detail, including static analysis commands you can run against any repository before executing it, an incident response checklist, and how this campaign family connects to broader documented threat actors.

Continue reading: Anatomy of a Developer Recruitment Scam - A Technical Deep-Dive

The scam described here targeted a specific professional community, but the underlying mechanics, including a false identity, a trusted process, and a hidden payload, apply across industries and job functions. The people most at risk are often the most capable: developers and technical professionals who trust their ability to assess what they are looking at.

The pattern can be learned. Once it is, it is very hard to miss.