I’m sorry what kind of a circus are you running where people with prod access run random untrusted code on the same boxes with credentials to prod systems?
I ran a fairly locked down ship - and I honestly find myself feeling like I should kind of stay quiet about that fact on places like HN.
The amount of "I've never work at a place where I don't have root and unlimited access" and "not having prod server access is a massive red flag" type posts are constant.
> Some generic SaaS company or tiny startup, yes, engineers should have root access to stuff.
Why? Setting up proper CI/CD is a 5 minute task. If you're worried about sharing keys with 3rd parties the pipeline can be self-hosted. There's no need for credentials to live on engineers' machines.
Please do not stay quiet. I think most of us know how incredibly difficult it is to lock things down without there being holes, and without impacting the team culture and killing productivity. If you managed to do that you have a lot of contribute.
That is completely normal at the companies i have worked at!
In one case i let slip something while talking to the CEO, and he said "but it's good that you guys don't do that, right? Otherwise we would be in alot of trouble with [name of regulatory authority]". And i said "yeah ofcourse we dont do that".
This is common in a lot of companies but specifically not for crypto custody due to insider risk. If an insider can jackpot for $6B by running a command on his laptop, either a malicious insider happens, or someone applies $5 wrench to the engineer or his kid, or takes over his laptop. It is like parthenogenesis.
In the real world, a great many regulatory rules — possibly the vast majority — are routinely violated in the corporate world. While many are well-meaning, and in theory, beneficial, I suspect total compliance would lead to the economy grinding to a halt.
I'm assuming a similar 'routine flouting of rules' is the rule in the public sector as well, and routine even in the regulatory agencies charged with enforcing the rules.
Wow yikes! On the one hand -- it's obviously a bad idea to use your current employer's laptop for a job interview.
But social engineering takes many forms and anyone could be suseptible.
Do we need to start carrying liability insurance (like doctors do)? There are so many hazards these days working in tech which can cause you to be liable for huge amounts of damage. Using agents seems fraught too; they can easily go "off the rails" and take actions you didn't intend.
Yeah. Pretty wild. I've never done that, and wouldn't, but I know folks who would. If I ever do any interview work on my laptop, it's always sandboxed, but generally, I just nope out of such interviews, anyway. It's usually one of many red flags.
It does seem like there has been an increase in that social engineering approach. The Rust ecosystem was being targeted recently too, enough that they felt the need to warn people about it: https://blog.rust-lang.org/2026/09/17/targeted-attacks/
Multiple wtfs: one dev can access 6B; the dev does job interview from the work laptop; the work laptop has permission to run random executables with it having access to sensitive stuff. Maybe they went on to hack into stuff from the dev's laptop that they should not have had access to.
Of course as usual the legacy media article fails to address that key issue. If I had to guess I'd say that their system uses some sort of HSM to sign chain transactions but there are not strong controls on what txn it will agree to sign. Therefore somewhere in their code there's a place where you can just insert your transaction du jour and it'll go through. Once you have that scenario anyone who can modify the system's code will be able to steal as much money as they want. So the "developer laptop" may have only been used to push a PR or perhaps change code via a more direct route -- publishing a new container image or other build artifact. Using AI tools I think it would be quite feasible to point an agent at the pile of code on that laptop and just ask it "what code do I need to change to allow any transaction to be sent on-chain"? So the attacker didn't need to have deep knowledge of the system.
Edit: Binance has now published some details on the attack. The attacker subverted an EIP-7702 contract rather than as I theorized an HSM authorization process.
7702 made the attack a bit more efficient but wasn’t critical. The core sin was the control plane to submit orders to the MPC signing system (I think it has been reported as MPC vs HSM but largely equivalent here) was not sufficiently isolated, and insufficient preventive controls and alerting on dev machines. But the number one thing for me is that devs could get access to replace signing control systems without a multiple person involved review and approval process. Plus $6.5B or more in assets in that system given that level of controls.
With this architecture honestly surprised a suborned insider didn’t steal the assets before this time. No need for outsiders if individual insiders can instruct a payment to be made.
(It is clear 7702 wasn’t core to this because non-eth systems using the same signing infrastructure were also compromised.)
I had a few long and fairly unpleasant calls with insurance markets over the past few days on this point as we do billion dollar insurance policies for similar risks; would have caught these during underwriting and raised with client and excluded or not issued until fixed.
The article in Fortune [1] says "According to a Binance spokesperson, employees with non-public-facing roles are not allowed to maintain LinkedIn profiles."
How common is that? I understand many companies asking employers to not list where they work (for security reasons). But, not allowed to have a LinkedIn profile, period.
I don't quite understand why so many people still don't use containers. You can easily use devcontainers in VS Code. That way, each repository has its own container, and the risk of infecting your system with malware is much lower.
While true, I tried it devcontainers recently for the first time and it was molasses slow for every keystroke in the terminal and action with files. Ended up putting dropbear in the container temporarily and sshing into it using the standard remote connection. That got it back to normal. I should see about filing a GitHub issue ticket
I prefer to do the vetting before running other people's code. If someone asks me to do a interview project that has a virus on it, I will just waste my time even if I don't get hacked.
A compromise of engineers' endpoints should not lead to a compromise of wallet keys.
> A limited number of engineers at the company have direct access to wallets
Ah, so security models I spec'd and implemented for operating/administrating sensitive resources in/of production or just anything non-prod in general over the last decade, which never ever allow human users direct access outside of "break glass" (immediately instant-termination offense and lawsuit from company against employee if used frivolously), are superior to Binance's security, apparently.
inb4 "but how do u do tings den": the model has only so much cleverness but not that much, I'll keep it proprietary for now thx
Ya'd think a place like Binance would use a managed Qubes OS offering for endpoints. And yes, Qubes can be made derpy-derp-friendly with a custom UI layer and backing of provider's cicd for any/all apps including Windows apps like MS Excel with full GPU support.
I’m sorry what kind of a circus are you running where people with prod access run random untrusted code on the same boxes with credentials to prod systems?
I ran a fairly locked down ship - and I honestly find myself feeling like I should kind of stay quiet about that fact on places like HN.
The amount of "I've never work at a place where I don't have root and unlimited access" and "not having prod server access is a massive red flag" type posts are constant.
This depends massively on what the company is actually doing.
Some generic SaaS company or tiny startup, yes, engineers should have root access to stuff.
A financial company as big as Binance, though, I'd expect a lot more controls.
Security isn't one size fits all, you need to determine what makes sense for your situation.
> Some generic SaaS company or tiny startup, yes, engineers should have root access to stuff.
Why? Setting up proper CI/CD is a 5 minute task. If you're worried about sharing keys with 3rd parties the pipeline can be self-hosted. There's no need for credentials to live on engineers' machines.
Please don’t stay quiet.
If it’s anything serious like a bank or critical infrastructure, hosting, sensitive data? Lock. It. Down.
Please do not stay quiet. I think most of us know how incredibly difficult it is to lock things down without there being holes, and without impacting the team culture and killing productivity. If you managed to do that you have a lot of contribute.
That is completely normal at the companies i have worked at!
In one case i let slip something while talking to the CEO, and he said "but it's good that you guys don't do that, right? Otherwise we would be in alot of trouble with [name of regulatory authority]". And i said "yeah ofcourse we dont do that".
Ooops
This is common in a lot of companies but specifically not for crypto custody due to insider risk. If an insider can jackpot for $6B by running a command on his laptop, either a malicious insider happens, or someone applies $5 wrench to the engineer or his kid, or takes over his laptop. It is like parthenogenesis.
Revoke licences then. Close shops. Seriously.
“X Y Z got hacked by A B C state actor”
Outside of something as spicy as stuxnet most of it is social engineering plus poor hygiene mixed with cowboy shit.
In the real world, a great many regulatory rules — possibly the vast majority — are routinely violated in the corporate world. While many are well-meaning, and in theory, beneficial, I suspect total compliance would lead to the economy grinding to a halt.
I'm assuming a similar 'routine flouting of rules' is the rule in the public sector as well, and routine even in the regulatory agencies charged with enforcing the rules.
Wow yikes! On the one hand -- it's obviously a bad idea to use your current employer's laptop for a job interview.
But social engineering takes many forms and anyone could be suseptible.
Do we need to start carrying liability insurance (like doctors do)? There are so many hazards these days working in tech which can cause you to be liable for huge amounts of damage. Using agents seems fraught too; they can easily go "off the rails" and take actions you didn't intend.
A one million dollar liability insurance policy wouldn't have helped much with a six billion dollar loss.
I wonder if it would in the sense that you’d be aware you have only a million covered so maybe don’t give them direct access to 6 billion.
When the risks get written down people tend to behave differently.
Contractors in the UK are already required to have liability insurance, or any large business won't touch them with a barge pole.
Same for contractors in the US, for the 20-odd years I've been doing it.
As a contractor yes you should have liability insurance. As an employee no, you can't be held liable for mistakes. Just proven malice.
At least that's how it works here in Europe.
Yeah. Pretty wild. I've never done that, and wouldn't, but I know folks who would. If I ever do any interview work on my laptop, it's always sandboxed, but generally, I just nope out of such interviews, anyway. It's usually one of many red flags.
I know several friends in IT who don't even have their own pc anymore, they use their work laptop for everything.
With the amount of spyware in modern EDR systems I can't imagine that but they do.
> On the one hand -- it's obviously a bad idea to use your current employer's laptop for a job interview.
Maybe they were quiet quitting..
It does seem like there has been an increase in that social engineering approach. The Rust ecosystem was being targeted recently too, enough that they felt the need to warn people about it: https://blog.rust-lang.org/2026/09/17/targeted-attacks/
This a known method now of social engineering. See this post from last year: https://news.ycombinator.com/item?id=45591707
Still crazy tho that one dev's compromised device could withdraw 6 billion...
Multiple wtfs: one dev can access 6B; the dev does job interview from the work laptop; the work laptop has permission to run random executables with it having access to sensitive stuff. Maybe they went on to hack into stuff from the dev's laptop that they should not have had access to.
Of course as usual the legacy media article fails to address that key issue. If I had to guess I'd say that their system uses some sort of HSM to sign chain transactions but there are not strong controls on what txn it will agree to sign. Therefore somewhere in their code there's a place where you can just insert your transaction du jour and it'll go through. Once you have that scenario anyone who can modify the system's code will be able to steal as much money as they want. So the "developer laptop" may have only been used to push a PR or perhaps change code via a more direct route -- publishing a new container image or other build artifact. Using AI tools I think it would be quite feasible to point an agent at the pile of code on that laptop and just ask it "what code do I need to change to allow any transaction to be sent on-chain"? So the attacker didn't need to have deep knowledge of the system.
Edit: Binance has now published some details on the attack. The attacker subverted an EIP-7702 contract rather than as I theorized an HSM authorization process.
7702 made the attack a bit more efficient but wasn’t critical. The core sin was the control plane to submit orders to the MPC signing system (I think it has been reported as MPC vs HSM but largely equivalent here) was not sufficiently isolated, and insufficient preventive controls and alerting on dev machines. But the number one thing for me is that devs could get access to replace signing control systems without a multiple person involved review and approval process. Plus $6.5B or more in assets in that system given that level of controls.
With this architecture honestly surprised a suborned insider didn’t steal the assets before this time. No need for outsiders if individual insiders can instruct a payment to be made.
(It is clear 7702 wasn’t core to this because non-eth systems using the same signing infrastructure were also compromised.)
I had a few long and fairly unpleasant calls with insurance markets over the past few days on this point as we do billion dollar insurance policies for similar risks; would have caught these during underwriting and raised with client and excluded or not issued until fixed.
The article in Fortune [1] says "According to a Binance spokesperson, employees with non-public-facing roles are not allowed to maintain LinkedIn profiles."
How common is that? I understand many companies asking employers to not list where they work (for security reasons). But, not allowed to have a LinkedIn profile, period.
[1] https://fortune.com/2026/11/03/binance-hack-details-linkedin...
Very common in some hedge funds and family offices.
I don't quite understand why so many people still don't use containers. You can easily use devcontainers in VS Code. That way, each repository has its own container, and the risk of infecting your system with malware is much lower.
While true, I tried it devcontainers recently for the first time and it was molasses slow for every keystroke in the terminal and action with files. Ended up putting dropbear in the container temporarily and sshing into it using the standard remote connection. That got it back to normal. I should see about filing a GitHub issue ticket
I prefer to do the vetting before running other people's code. If someone asks me to do a interview project that has a virus on it, I will just waste my time even if I don't get hacked.
So Binance lets its developers download code onto machines that have access to production material willy-nilly?
Seems like they have some developers who don't take security seriously. I guess it's other people's money after all.
Some more discussion: https://news.ycombinator.com/item?id=50353353
A compromise of engineers' endpoints should not lead to a compromise of wallet keys.
> A limited number of engineers at the company have direct access to wallets
Ah, so security models I spec'd and implemented for operating/administrating sensitive resources in/of production or just anything non-prod in general over the last decade, which never ever allow human users direct access outside of "break glass" (immediately instant-termination offense and lawsuit from company against employee if used frivolously), are superior to Binance's security, apparently.
inb4 "but how do u do tings den": the model has only so much cleverness but not that much, I'll keep it proprietary for now thx
Ya'd think a place like Binance would use a managed Qubes OS offering for endpoints. And yes, Qubes can be made derpy-derp-friendly with a custom UI layer and backing of provider's cicd for any/all apps including Windows apps like MS Excel with full GPU support.