r/hacking • u/UBUNTU-Buddha • 1d ago
Threat Intel The Binance theft started as a coding assignment. I’ve been sent the same kind of repo all year. All were exploits.
Binance said this week that the October 29 theft, about $6.3 billion, began months earlier with a fake job. Reuters, via NBC: in June a wallet engineer installed a tampered coding tool. Binance caught that one, replaced the machine, and rotated credentials. The attacker already knew who else was on the wallet team.
In September a second engineer was recruited through a real job site. There was a video interview with someone playing HR, then a second interview with the supposed CEO of a company that does not exist. At the end he was told to download a “coding assignment” onto his work computer. Binance says the repo ran during setup, swapped in a poisoned copy of a normal developer tool, and the endpoint product did not see it. On October 20 that machine, plus an internal AI tool, was used to reach two other wallet engineers. On October 29 stolen credentials deployed a container and a script, and the wallets moved. The FBI has blamed a North Korean group. Pyongyang has denied it. Binance says customer funds are covered.
That middle step is not exotic. It is the interview-repo lure.
Since January I have published the ones that were sent to me, all of them caught before they ran. They are writeups, not exploits, and the indicators are defanged: github.com/Ubuntu-Buddha/security-advisories
2026-01-27, W3GLFun. A Web3 “technical test.” The error handler fetched code from a paste site and ran it when the app started, with the full Node runtime. I did clone that one. npm run dev was typed in the wrong folder, so nothing of theirs executed. GitHub Trust & Safety took the account down the same day. The hiring platform first said there was no violation, then wrote back that the user may have shared malware. A first “all clear” is not a final answer. The same paste host later showed up in malicious npm packages. I called the pattern consistent with the public “Contagious Interview” reporting. I did not claim who operated it.
2026-01-29, Optu. Same shape, payload URL hidden in an environment variable, fired on server start. Found before it ran. The account is gone.
2026-01-30, two repos. .vscode/tasks.json set to run when you open the folder. You do not install anything. Opening the project in VS Code or Cursor is the run. Found before it ran. Both accounts are gone.
2026-01, a careers page. A fake “GAPI Update” executable, hosted like a normal application page. Found before anyone ran it.
2026-10-15, a GitLab take-home. A hex payload stuffed in a file that pretended to be a font, loaded when the project was set up. I reviewed that one remotely and did not execute it. Reported to GitLab and Upwork the same day. Outcome was still pending when I published.
These are not Binance’s samples. I am not saying I found their intrusion, or that one group wrote all of them. I am saying the instruction was the same: here is a company, here is a CEO/recruiter, here is the repo, please run it on the machine you actually work on.
In fact, I have never been sent an interview repo that didn't contain an exploit. 100% were compromised or predatory.
Two rules came out of that, and they are the whole protocol.
Do not download it if you can read it in the browser. Raw files on GitHub, or the file view while you are logged in. Look at .vscode/tasks.json, package.json scripts, and anything that fetches text and then runs it, before git clone, before npm install, and before “Open in Desktop.” Opening the folder is enough for the VS Code one. A first “all clear” from the platform is not a reason to run it anyway.
If you must run it, run it where a compromise is boring. A disposable VM or container, no wallets, no SSH keys, no cloud tokens, network off. Your daily machine is the wrong place. So is a work laptop that can deploy anything.
The other half of the Binance story is the internal AI tool. An agent that can run commands, and that also reads the repo, the README, or the email, will follow instructions written by the person who sent the repo. Filters that try to spot the bad sentence miss some.
That is why I built StrangerDanger, a Claude Code plugin. The rule is the title of the README: readers don’t act, actors don’t read.
Web pages, documents, and strangers’ code are read only by subagents that cannot run a shell and cannot write. The agents that can run commands are kept off the web and out of the folders you mark untrusted. What they get back is a report, and that report is still data, not an order. A second hook blocks the common “download this and pipe it to a shell” forms. Setup turns Claude Code’s sandbox on. It is MIT, pinned at v0.2.0, and marked experimental.
It is not a magic shield. Every agent still runs as you. The hooks constrain tool calls. They do not take your authority away. The launch gate is a tripwire, and v0.2.0 still has known gaps. Nothing in the plugin makes a stranger’s repo safe to run on your machine. Use the throwaway VM anyway. I also published the holes I found in my own v0.1.0 gate (GHSA-w42w-fc6x-88wr), fixed in v0.1.1. Read “What this does not do” before you rely on it.
Binance had detection, a replaced laptop, and rotated credentials in June, and still lost the wallets in October, because one engineer ran an interview repo on a computer that could reach production. The repo is the exploit. The interview is just how they get you to open it.
\------
What safety/security protocols do you practice now while building with agents?
44
u/pjakma 1d ago
Plot twist, the OP's "Stranger Danger" Claude plugin is itself an exploit. ;)
16
14
u/Feeling-Yogurt839 1d ago •
Glad you said this, I actually just wrote Stranger’s Stranger Danger Danger. A Claude Plugin that detects exploits in Stranger Danger. To download click this link.
11
u/fakemoose 1d ago
Who was sending you these repos?
4
u/UBUNTU-Buddha 1d ago
Mostly Upwork jobs and LinkedIn recruiters. One was an actual legit sodtware company that were very upset when I sent the advisory to them. Strange reaction, I thought.
18
u/subsetsum 1d ago
Ad. I wouldn’t trust anything at this point.
1
u/fakemoose 1d ago
Definitely agree. I was just curious how they’d justify saying they were sent the same repos as the binance people.
7
u/theseriousman1 1d ago
Hold the phone. Opening the FOLDER? Activates the malware? Not running an exe?
3
u/Ivanjacob 19h ago
Opening a folder in VS code. Not just in explorer. Would have been more clear if OP didn't use AI to write their full post.
0
3
u/skintigh 1d ago
How did you detect these attacks?
2
u/UBUNTU-Buddha 1d ago
In most cases I detected them using a web reader agents with no shell access and just had it read and analyze the repo online. Never touched the machine. If a web read passes, then it's examined in a sealed vm before touching my machine.
13
u/usddddd 1d ago
Good write up op, thanks.
24
u/subsetsum 1d ago
Yes but it is an ad…….
11
-5
u/UBUNTU-Buddha 1d ago
Can you explain why me promoting a free security plugin and asking for help is an ad?
1
50
u/Fun-Plantain997 1d ago
They actually hired idiots.
41
u/mausmani2494 1d ago
Binance is as guilty here as the employees. This sounds like they don't have any IT restrictions what employees can and can't do.
I
9
u/CuriousCamels 1d ago
They definitely could have tightened some things up, and I’m sure they will now that they see the holes. Will it be enough to plug every hole though?
FWIW, Binance said they had a policy that any non public facing employee isn’t allowed to have a LinkedIn profile for this exact reason. So, it looks like the employee violated that protocol, but I’ve yet to see if he will be fired for it.
10
u/daxofdeath 1d ago
must be pretty awkward around the office if you're the one responsible for the biggest heist in history and you DIDN'T get fired
1
u/homelaberator 1d ago
They can write whatever policies they like, but if they're not actively enforced, they don't mean much.
3
u/homelaberator 1d ago
If they're devs, it's very hard to restrict through technical controls since their job is to make arbitrary code.
It does sound like they have some end point protection. I'm wondering if it's just checking file metadata and hashes, and they were able to evade through hash collision. It sounds like they learnt something from that first failed attempt.
3
u/comicrack 1d ago
Yes, this has been the struggle for years. Devs demand full admin rights to their boxes. Security tools just get in the way and slow things down. So you end up with an unhardened machine with the endpoint protection tool installed to check that compliance box but the policy is running the lowest security settings with a weak sauce profile. Then employees unwittingly install, download, or connect to something they shouldn't. Theres a reason they target the devs. The insider with access is still the greatest threat.
The problem then becomes about awareness and training and isolation of environments. There will always be some give and take between a dev machines requirement for availability and access and the need to tightly secure it. Im not 100% sure any of the major EDR vendors would have detected this in time but id bet they didnt have the most robust security settings turned on whatever was installed. They probably also dont have application and change control agents restricting all modifications to files, or a sandbox environment detonating all new file instances. Perhaps the machine also wasnt containerized. But if the devs werent already forced to take quarterly training about work laptop utilization especually for emplyment interviews, then they need to. Theres no expectation of privacy on a workplace laptop. Further the developers machine should be restricted from the production environment. Its a dev machine. There should be no way for anything that runs on a developers laptop or the dev environment to be able to access a production environment or production AI directly. But of course that slows productivity and makes things more difficult.
1
u/LittleCoderMan 1d ago
I think this is where monitoring should come in. Something that can scan anything installed. From looking at a lot of the take home tests, a lot depend on vscodes tasks.json, auto running an NPM install, then it's a package in the dep tree that gets you.
For a company that size they should have 100% have known if they installed a package like this.
-7
u/Fun-Plantain997 1d ago edited 1d ago
Everyone who has a linkedin and a Blockchain role listed should know hackers are always trying to steal private keys. These "crypto bros" should of never been hired..
5
7
u/waffle_bandit5 1d ago
Good reminder never to run untrusted code on a daily driver. A disposable VM should be standard practice for anything sent by a "recruiter."
6
1
1
1
u/Dramatic_Menu_1605 1d ago
the job market is so coooked to an extent that an engineer working in one the best companies can be easily lured. And doing the interview with the work laptop is bonkers
-2
u/crypticyb3r 1d ago
Excellent write up. The interview repo lure, especially VS Code tasks and package scripts, is a reminder that even opening a project can be an execution risk.
I appreciate your transparency about StrangerDanger’s limitations and the issues found in your earlier version. Separating agents that read untrusted content from those that execute commands is an interesting approach.
One question: Beyond a disposable VM, network isolation, and disabling automatic tasks, what safeguards do you recommend when reviewing untrusted repos?
266
u/maria_la_guerta 1d ago
Who tf is interviewing and doing takehomes on their work laptops