The code review that was the attack

Last week an enquiry arrived through the form on our website. A company we had not heard of was building a cryptocurrency exchange. It had a working prototype, a budget of a hundred thousand dollars and a three-month deadline. Would we review the code and say what could be kept? The next morning one of us was given access to the private source code and asked, politely, to set it up and run it, to check that it worked.

We did not run it, and not by accident. The request we had accepted was a review, and a review is reading. Twenty minutes into the reading, the reason it should never run was on the screen.

What was in the code

Hidden in the file that loads the program's settings was a short block that no settings file has any business containing. Each time the software starts, it contacts a numbered address on the internet, downloads whatever text is waiting there and executes it with full access to the machine. Whoever controls that address controls any computer that runs the program. The rest of the code was ordinary. That block was the point of the exercise.

Everything we checked afterwards lined up. The company's web address had been registered seven weeks earlier and still showed the hosting firm's “parked domain” page. Its code-hosting account was created the same day as the invitation, minutes before the invitation itself. The software was a copy of a small open-source project by an unrelated developer, renamed, with that developer's name and email forged onto the changes that added the trap. A public copy of the same project existed, dressed with a few plausible bug reports, and that copy was clean. The poisoned version is the one you receive after you say yes.

This is a known campaign, not a one-off. Microsoft described the pattern in March: attackers posing as recruiters or clients at cryptocurrency and AI companies invite a developer to download a “coding assessment” which, when opened or run, fetches a backdoor. In September The Hacker News reported that the same campaign had compromised around 30,000 devices in more than 100 countries and emptied over 7,000 cryptocurrency wallets. Those figures are the reporters', and we repeat them as reported. What gets taken is whatever the machine can reach: wallets, saved passwords, the keys to a company's cloud accounts and the tokens to its code hosting. For a software company that last one is the way into every client's work at once.

Why it never ran

Two habits did the work, and neither is exotic.

The first is a boundary. The email asked us to run the software “where feasible”. The brief we actually gave the reviewer was narrower: assess the code, nothing more. Nobody had written that down as a security rule. It was there because it is how we think a review should be done, and on the day it held.

The second is how the reading was done. Every review we do now starts with an AI assistant reading every file before a person opens one, the boring settings files included, and it flagged the block on its first pass. It did not find the trap by being clever. It found it by reading all of it, which is the part a busy human skips. The decision that followed was a human one: run nothing, tell everyone, delete the copy.

Here is the honest part. Would we have been as careful three or four years ago, before that assistant was part of every review? We would like to think so. We will never know, and that is the uncomfortable lesson. A process that depends on someone being careful on the day is not a process. Ours held by a narrower margin than we would like, and we have spent the week widening it.

The signs that were there before the code

Every one of these was visible before anybody looked at a line of source, and none of them stopped us. Replies to our emails came back within six minutes, at what was supposedly eleven at night in the sender's time zone. The budget and the timescale did not fit the wish list: a regulated exchange holding customer money, built in three months for that sum, is bait shaped like a plan. A confidentiality agreement was mentioned twice and never arrived. Every exchange was by email; nobody on either side ever heard a voice. Any one of those has an innocent explanation. Together they should have slowed us down, and they did not.

The checks we would suggest to any company that receives code

Write the boundary down. A review is reading. Running someone else's software is a separate decision, made deliberately by someone who knows what could go wrong, never a courtesy to a prospect.

If something must run, it runs on a disposable cloud machine with no logins, no keys and nothing on it worth taking, and that machine is deleted afterwards. A genuine client will understand at once; it is the care they would want applied to their own systems.

Before anyone opens a stranger's code, five minutes of checking comes first. How old is the web address, and is there a real website behind it? Does the company appear in a public register, Companies House here or its equivalent abroad? Can the person who wrote to you be found anywhere else? Have you spoken to them, by phone or video at the least, in person if you can? A “no” to all of those is a stop, however good the brief sounds.

Read all of it. Not the interesting files, all of them. A tool that never skims earns its keep in exactly the places a person would not bother, which is the same reason we test AI on the worst-looking documents rather than the tidy ones.

Decide the stop conditions before the enquiry arrives, so that eagerness does not get a vote on the day. Small firms handle new business eagerly. That eagerness is what this campaign is built to use.

The sample sent for inspection was itself the trap. Our process caught it, if only just, and writing it down is how we make sure “just” is not the margin next time. If a prospective client's first request is that you run their software, the answer is that you will read it, gladly, and run nothing. A genuine client will understand. The other kind will stop replying, which is also an answer.

If you have been sent code to assess and something about the request feels off, you are welcome to ask us before you run it: get in touch. That question costs nothing.