Have you ever clicked on a LinkedIn message that looked too good to ignore? A recruiter from a crypto firm, a role that matched your skills, and an interview process that felt almost professional. That is exactly how one company in Singapore lost 11.8 million dollars. The message was fake. The coding test was malware. And by the time anyone realized something was wrong, the money was already gone.
How a Single Fake Job Offer Emptied Corporate Crypto Wallets
It started the way so many modern attacks do. Someone sitting at a company laptop received a message on LinkedIn. The sender claimed to be a recruiter from a cryptocurrency company. The conversation felt normal at first. Then it moved to email. The domain looked almost right, just different enough that most people would miss it. A few video interviews followed on Google Meet. The interviewer kept the camera off the entire time. Looking back, that should have raised a flag. At the time it did not.
The final step felt like a standard technical assessment. The candidate was asked to complete a coding task on a company-issued device. The site looked legitimate. The instructions seemed ordinary. Somewhere in that process, malicious software installed itself without any obvious warning. From that moment the attackers had a foothold.
The Moment the Session Token Was Stolen
Once the malware was running, it quietly collected a session token. That single piece of data was enough to bypass multi-factor authentication. The attackers walked into the employee’s Bitbucket account as if they belonged there. Bitbucket is where many development teams keep their source code and deployment scripts. Access to one account can mean access to far more than a single laptop.
With the repository open, the attackers changed the company’s automated deployment instructions. They moved from the code repository into internal servers. Credentials gathered during the compromise let them override transaction limits and approval checks that were supposed to protect crypto transfers. The result was a series of unauthorized moves that totaled 11.8 million dollars.
I keep thinking about how ordinary the early steps must have felt. A LinkedIn message. A few interviews. A coding test. Nothing about it screamed “this will cost us millions.” That is what makes these attacks so effective. They do not look like attacks until it is too late.
Why Coding Assessments Make Perfect Delivery Vehicles
Developers are used to running code. They download repositories, install packages, and test environments as part of their daily work. A technical assessment that asks them to do exactly that on a company machine does not trigger the same suspicion a random email attachment would. Attackers know this. They have used similar tactics for years against crypto and Web3 teams.
In one earlier campaign, malicious packages appeared across popular language ecosystems. Those packages targeted wallet data, GitHub tokens, API keys, and SSH credentials. The goal was the same: turn a developer’s workstation into a gateway. Once inside, the attackers could reach far beyond the individual machine.
Another series of incidents used LinkedIn and messaging apps to approach professionals in crypto and finance. Targets were persuaded to install community plugins for a legitimate note-taking tool. The plugins turned out to be malware that used blockchain networks for command and control. Legitimate software became the entry point.
These patterns keep repeating because they work. People in technical roles expect to interact with code and tools. That expectation is exactly what the attackers exploit.
The Growing Pattern of Recruiter-Based Attacks
Recruitment-themed social engineering has become a reliable method for groups that target the crypto industry. In some cases the attackers pose as recruiters from real or fictional companies. They conduct multi-stage interview processes that feel thorough. The final stage almost always involves running something on the target’s machine.
One long-running operation linked to state-sponsored actors used LinkedIn and other platforms to approach employees at crypto firms. Victims were convinced to run malicious containers. Those containers installed backdoors and downloaders. From there the attackers moved through internal networks, harvested credentials, and looked for systems that handled cryptocurrency transactions. In at least one incident they managed to disable multi-factor authentication on a privileged cloud account.
Authorities investigating the Singapore case have not publicly tied it to any specific group. Still, the technique fits a well-documented playbook. The combination of professional social platforms, spoofed domains, and technical assessments creates a path that many security tools do not catch until the damage is done.
The most dangerous attacks often begin with something that feels completely normal.
What Companies Should Change Right Now
Singapore authorities released clear recommendations after the incident. The advice applies far beyond one country or one industry. Anyone working with code repositories, deployment pipelines, or cryptocurrency transfers should take it seriously.
First, treat unsolicited recruitment approaches with real caution. Independently verify the recruiter and the company before downloading anything or running code. A spoofed domain can look almost identical to a legitimate one. A few extra minutes of checking can prevent months of cleanup.
Second, protect credentials and session tokens with the same intensity you protect private keys. Session tokens that bypass multi-factor authentication are high-value targets. Regular rotation, short lifetimes, and monitoring for unusual use can limit the damage if one is stolen.
Third, lock down code repositories and deployment systems. Access to Bitbucket or similar tools should never give an attacker a straight path into production infrastructure or transaction controls. Separation of duties, strict approval workflows, and monitoring of changes to deployment scripts matter more than most teams realize until something goes wrong.
- Verify every recruiter and company independently before any technical assessment
- Never run unfamiliar code or install packages on a company device during a job process
- Limit the lifetime of session tokens and monitor their use
- Require multiple approvals for changes to deployment pipelines
- Isolate any device the moment compromise is suspected
If a device or account is already compromised, isolation comes first. Revoke active sessions. Reset credentials. Review access logs for signs that the attackers moved into other systems. Check whether repositories, servers, or approval workflows were altered. Bring in internal security teams or external specialists without delay.
Why Developer Environments Remain High-Value Targets
Developers sit at the intersection of code, credentials, and production systems. Their machines often contain tokens for cloud platforms, source control, continuous integration services, and sometimes even production access. A single compromised workstation can therefore open multiple doors.
Attackers understand this better than most security teams. They do not need to break through perimeter defenses if they can simply persuade someone inside to run malware. The social engineering step is often the hardest part for defenders to stop because it targets human judgment rather than technical controls.
In my view, the industry still underestimates how attractive developer workstations are. Companies spend heavily on wallet security and transaction monitoring while leaving the path that leads to those systems relatively open. The Singapore case shows what happens when that path is used successfully.
Practical Steps for Individuals Working in Crypto
If you work in the space, the next unsolicited job message deserves extra scrutiny. Ask yourself a few simple questions before responding. Does the company have a real online presence that matches the claim? Can you verify the recruiter through official channels rather than the contact details they provided? Is the interview process pushing you toward downloading files or running code on a work device?
When a technical assessment is required, insist on using a disposable environment that has no access to company accounts, repositories, or wallets. Virtual machines or isolated containers that can be wiped afterward reduce the risk dramatically. If the other side refuses that condition, treat it as a warning sign.
Keep personal and work environments separate. Never use a company laptop for job applications or coding tests that come from outside your current employer. The device that has access to internal systems should stay away from untrusted code.
The Human Element That Technology Alone Cannot Fix
Multi-factor authentication, hardware wallets, and approval workflows are necessary. They are not sufficient on their own. The Singapore attackers bypassed transaction limits and approval checks after they already had credentials and access. Technical controls failed because the initial compromise gave the attackers enough privileges to override them.
Training helps, but only if it stays realistic. Telling employees to “be careful with LinkedIn messages” is too vague. Concrete examples of how these scams unfold, including the camera-off interviews and the coding assessment step, make the risk feel real. People remember stories better than checklists.
Perhaps the most useful change is cultural. Teams that treat every unexpected technical request with mild suspicion tend to catch more of these attempts. Curiosity about who is asking and why should be encouraged rather than dismissed as paranoia.
Lessons That Apply Beyond Crypto
Although this case involved cryptocurrency transfers, the underlying method works against any organization that relies on code repositories and automated deployment. A compromised developer account can lead to supply-chain attacks, data exfiltration, or ransomware just as easily as it can lead to emptied wallets.
The same recommendations apply. Verify recruiters. Isolate untrusted code. Protect session tokens. Monitor changes to deployment systems. Treat developer workstations as high-value assets rather than ordinary employee devices.
I have seen too many post-mortems that focus on the final transaction while ignoring the path that made the transaction possible. The malware was only the first step. The real failure was the lack of barriers between a single infected laptop and the systems that controlled large amounts of value.
What to Do If You Suspect a Similar Breach
Speed matters. Isolate the affected device or account immediately. Do not try to investigate while the machine remains connected. Revoke sessions and rotate credentials for every service the compromised account could reach. Examine logs for signs of lateral movement. Review recent changes to repositories, deployment scripts, and approval workflows.
Contact your internal security team or an external incident response provider without waiting for perfect information. The longer the attackers remain inside, the more they can take or destroy. In the Singapore case the financial damage was already done by the time the intrusion was discovered. Earlier detection might have limited the loss.
Document everything. Preserve logs and memory images if possible. The details will matter both for recovery and for any future legal or regulatory process.
A Quiet Warning for the Entire Industry
Eleven point eight million dollars is a large number. It is also only one incident. Similar techniques have been used against other firms with varying degrees of success. The pattern is consistent enough that every team working with crypto or code repositories should assume they will face a version of this attack eventually.
The attackers do not need zero-days or exotic exploits. They need one person to believe a job offer is real long enough to run a piece of code. That is a low bar, and it will stay low until organizations make the process of verifying recruiters and isolating technical assessments as routine as checking a signature on a smart contract.
I keep coming back to the camera that stayed off during the interviews. It seems like such a small detail. Yet it is one of the few signals that something was wrong before the malware ever ran. Paying attention to those small signals is part of staying safe in an environment where professional communication and social engineering look almost identical.
The next time a recruiter reaches out with an exciting crypto opportunity, pause. Verify. And never run their code on a machine that has access to anything valuable. The cost of caution is a few extra minutes. The cost of getting it wrong can be measured in millions.
Companies that treat developer security as a first-class concern rather than an afterthought will be better prepared. Those that continue to rely solely on transaction controls and multi-factor authentication will keep discovering, after the fact, that those controls were never designed to stop an attacker who already owns the keys.
This incident is a reminder rather than a surprise. The methods were known. The targets were predictable. The outcome was expensive. The only question left is how many more companies will learn the same lesson the hard way before the industry adjusts.
