New age (cost) of endpoint supply chain security
Adam Selby & Joe Nash
Binance has made some big headlines: the largest ever crypto heist with $6.34B in assets lost to North Korean attackers. With a timeline lasting months, the full sequence of events that led to the heist. But the story so far combines software supply chain security and social engineering to make an important warning to security teams: even the most seemingly innocent information can be used by an attacker.
Customer data, API keys, proprietary code, these are the types of things we look to secure after an attack. Who thinks about the job titles of staff? Join us as we explore what’s known about the attack, the root cause, and how you can proactively protect your fleet with organization sanctioned install paths.
What happened: A new style of attack
June 2026
Engineer A from Wallet DevOps team falls victim to a malicious ad masking as a Homebrew installation. A tampered Homebrew installation was used to install a popular AI coding tool. The security team followed protocol by replacing the device, and proactively rotated all credentials to reduce impact of the breach. Whilst this appears to have prevented the breach of any sensitive data, the attackers walked away with information about the team: the name and role of the user of the compromised laptop, and those of his team members on the wallet team. They had an in.
September 2026
3 months after the initial compromise, the attackers began a social engineering campaign targeting other Binance engineers. Engineer B was engaged in a false recruitment campaign for a fictitious company. The attackers used profiles on legitimate platforms to reassure Engineer B of their authenticity, leading the engineer through multiple stages of the process, culminating in a coding assignment.
The assignment code contained malware, which once downloaded and executed by Engineer B, kicked off the next stage of the attack.
<CREATE /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_
MODIFY pyenv_ → 3,414 B
DELETE .../libexec/pyenv (3,344 B) ← remove the valid pyenv
RENAME pyenv_ → pyenv (3,414 B) ← replace it with a malicious version
DELETE /opt/homebrew/bin/pyenv (3,414 B)
ln (create a new symlink) + spawn zsh
>
Source:https://x.com/binance/status/2117626126214504729
October 20, 2026
4 months on, the seemingly innocent data retrieved from Engineer A comes back into the picture. Using the access granted through Engineer B, the attackers leveraged internal AI tools to regain access to Engineer A’s machine, as well as the machine of another member of the wallet team, Engineer C.
October 29, 2026
The two compromised machines gave the attackers the components they needed to execute the heist. A token was retrieved from Engineer A’s machine that allowed the deployment of a container on Engineer C’s machine, firing the script that drained the wallet.
What went wrong: self-serve vs. company sanctioned install
The root cause of this incident is a combination of two issues we’re deeply familiar with: the targeting of Homebrew by malicious actors, and self-serve software installation.
This kind of attack is unfortunately not new, with attackers placing malicious installers on lookalike sites boosted in ad results. These are intended to mislead people looking for Homebrew, and catch them before the sites are flagged by Google Safe Browsing. Homebrew is already core infrastructure for developers — and increasingly also for other employee groups, thanks to agentic workflows.
As such a key component, it is vital that organisations administer and monitor Homebrew installation within their fleets. A supply chain security strategy needs to be centralized on company sanctioned installs, with guardrails built in from day one. The speed, scale, and complex techniques to conceal compromised software marks a new age of security supply chain attacks.
What you can do: secure by default with Workbrew
For most developers (and in fact, the default recommended way) that need to install Homebrew do so by curling and running a bash script. However, for a few years now Homebrew has shipped its own PKG installer. This means you as an admin can distribute Homebrew via your device management service so your users are not searching for “install Homebrew”. You can see immediately that this reduces some of the risk here, by reducing self-serve software installation.
Workbrew goes beyond this, offering your organization a sanctioned install path that comes with the governance you need. Workbrew ships with its own signed copy of Homebrew, bringing additional security features to Homebrew in enterprise.
With Workbrew, you get visibility: You’ll see installed packages, their versions, as well as security vulnerabilities. You also get governance: You’ll have policies to automatically install updates, patch vulnerabilities, and even block specific packages. Workbrew enables you to not only prevent compromised package installs like Binance’s but also to resolve the situation should it happen. And now, Workbrew supports more than just Homebrew.
Take a look for yourself: Workbrew’s Team plan includes access to package observability in the Console, and support for unlimited devices. Sign up for the free plan today