On 3 November 2026 the cryptocurrency exchange Binance described how attackers stole assets worth roughly 6.4 billion dollars. Technically it is a familiar story. A program that had no business being there started on the work computer of a developer. An attack can begin the same way in any company, except that instead of crypto wallets it ends at file shares, servers and cloud accounts.
What happened
The summary below is based on the statement the exchange published on 3 November 2026, as reported by the specialist media listed in the sources. The attack had two stages and ran for several months. Estimates of the stolen amount differ: the exchange speaks of about 6.3 billion dollars, the analytics company Elliptic of 6.43 billion.
June 2026. An engineer from the team that runs the wallet infrastructure searched the web for a popular AI coding tool and downloaded a tampered installer of Homebrew, the package manager used to install software on macOS. The malware ran during installation and replaced one component of a development tool with its own version. The exchange says its endpoint protection tools did not detect it at the time. The company did spot suspicious activity, replaced devices and rotated credentials, but the attacker already knew the engineer's role and who else worked in the team.
September 2026. The attacker approached another engineer through a legitimate job platform, posing as a project director, and offered him a job. The first interview round was a video call with a recruiter who shared a social media profile to look credible. The second round was held in a chat application by someone claiming to be the chief executive of the company. At the end the engineer was given an assignment, a normal part of technical hiring. He downloaded the code repository onto his work computer and the code executed during setup. Antivirus did not catch the malware, and the attacker also removed forensic artefacts.
Spreading and the theft. On 20 October the attacker used the compromised computer and abused an internal AI tool to take control of two more engineers' computers. On one of them he found a token with permission to deploy containers. On 29 October between 17:15 and 19:56 he logged on to a third engineer's computer, deployed a container with the stolen credentials, ran a malicious script and reached the internal service that signs wallet transactions. Transactions then left outside the normal withdrawal process. According to news reports, the FBI attributed the theft to the North Korean group TraderTraitor.
The exchange stresses that this was not a single isolated breach or a simple phishing incident. During 2026 its team says it identified 57 suspected cases linked to North Korea, ranging from fake job interviews to malware disguised as developer tools, compromised packages and browser extensions, and fake video conferencing applications.
Why this is not only a crypto exchange problem
Both stages share one common denominator. A user downloaded and ran a program on a work computer that nobody had approved in advance. First an installer from search results, then code from an assignment set by a fake employer. Detection failed in both cases because the malware was new.
In a company that has nothing to do with crypto the same thing looks more ordinary. A fake browser update, an installer for a PDF tool from the first search result, a macro in an attachment that pretends to be an invoice. The outcome is the same: attacker code runs on a workstation and the next step is credentials, tokens and file shares.
Users should not install software
The first measure is the dullest and the most effective. Ordinary users do not have local administrator rights on their computers and do not install software. They get the programs they need from an internal application catalogue, or IT deploys them.
This has two effects. An attack that needs an installation fails immediately, and the company knows what runs on its workstations, which is the precondition for the next step. Exceptions always appear, developers in particular, which is exactly why a second layer is needed.
Only approved applications run
Antivirus and EDR block what they recognise as malicious. Application control, also called allowlisting, works the other way round. Only what is on the approved list may run and everything else is blocked, regardless of whether anyone has seen it before. That is how malware nobody has met yet gets covered. Windows offers three tools for this and none of them is bought separately.
Software Restriction Policies
The oldest of the three, available through Group Policy since Windows Server 2003. It can define which executables and scripts may run and supports a highly restricted configuration where only listed applications start. Microsoft keeps its documentation with older versions of the system, most recently Windows 8.1 and Windows Server 2012 R2. Do not choose it for a new deployment. If it is still enabled in your domain from the past, treat it as a historical layer rather than current protection.
AppLocker
Introduced with Windows 7 and present in Windows 10, Windows 11 and server editions. Rules can be based on the publisher signature, product name, file name and version, the path on disk or the file hash. They cover executables, scripts, installers, DLL libraries and packaged apps. Compared with the newer tool it has two advantages: rules can be assigned to individual users and groups, and the same policy can be enforced on older systems. It is deployed through Group Policy or mobile device management (MDM).
It also has a limitation worth knowing. Microsoft itself states that AppLocker is a defence in depth feature rather than a defensible security feature with guaranteed fixes for bypasses. It no longer receives new functionality, only security fixes.
App Control for Business
Formerly Windows Defender Application Control (WDAC) and before that part of Device Guard. It arrived with Windows 10 and Microsoft treats it as a security feature under the servicing criteria of its security response centre (MSRC). Rules can be based on the code signing certificate, on file metadata or the file hash, on application reputation from the Intelligent Security Graph, on the identity of the process that performed the installation (managed installer), and on the path on disk. The policy applies to the whole device and to all its users. It is deployed through Intune, Configuration Manager or PowerShell, and through Group Policy only in a limited form.
The guidance from Microsoft is clear. Organisations that can build application control on App Control should do so. AppLocker fits environments that mix older and newer Windows versions, or where rules must differ per user on shared computers, and it works as a complement to App Control for fine tuning.
How to roll it out without stopping work
- Enable the policy in audit only mode and spend several weeks collecting what actually runs in the company. Without that list the rules cannot be written.
- Build the rules from the collected data. Signed vendor applications and in-house applications form the basis, plus a short list of exceptions.
- Enforce on one group first, typically office computers without development work, and then move on.
- Keep path based rules to a minimum. A directory the user can write to cannot be allowed, otherwise the attacker simply places a file there.
- Handle developer machines separately. Listing what is allowed is hardest there, and a separate environment or a virtual machine for third party code is the better route, without production credentials and tokens.
What EDR adds
Modern EDR tools (endpoint detection and response) offer similar capabilities by a different route. In Microsoft Defender for Endpoint you can create file indicators, rules that block or allow a file by its hash. A blocked file cannot be read, written or executed. This covers portable executable files, that is .exe and .dll, and requires Microsoft Defender Antivirus in active mode and file hash computation enabled. Blocking by hash or signature and attack surface reduction rules exist in some form in most EDR products; the naming and the scope differ.
The limitation from the start of this article applies here too. In this incident the malware was new and endpoint protection tools did not recognise it. Indicators and detection help only once you know what to look for. Application control is therefore a layer that EDR does not replace, and the other way round.
User training and basic hygiene
Few people would see through a two round interview with a video call, a social media profile and someone posing as a chief executive. The goal of training is not for your people to uncover an operation like that. It is to give them the basics that work against the attacks arriving every week.
- Recognise phishing. Unexpected urgency, a request to sign in through a link, an attachment nobody expected, and pressure to bypass the normal process.
- Do not run code or installers from unknown sources on a work computer. Software is IT business, and personal and work activities do not mix.
- Be careful when searching for tools. Paid links and spoofed pages with fake installers are a common way for malware to reach a workstation. That is exactly how the first stage of this attack started.
- Report anything suspicious immediately, even if someone has already clicked. Where reporting is punished, the company learns about the incident too late.
Training is worth repeating and pairing with a phishing simulation that shows where the company really stands. Training for IT staff and for management is especially useful, because the more elaborate attacks aim at them.
What to do now
- Find out how many users have local administrator rights on their computers and remove them from everyone who does not need them for work.
- Enable application control in audit only mode and find out what runs in your company.
- Review what your EDR can do and turn on blocking by hash and attack surface reduction rules.
- Separate developer and test machines from environments holding production credentials and tokens.
- Add two things to your training: recognising phishing, and the rule that only IT installs software on work computers.
How we can help
We run training for staff, IT teams and management, together with phishing simulations, as part of our security awareness service. With selecting and deploying tools, including application control and EDR, we help through technology selection and deployment, independently of any single vendor. If you only want to check where to start, get in touch; the initial consultation is free of charge.
Sources: The Hacker News, the incident as described in the statement from the exchange on 3 November 2026 · BleepingComputer, the fake job interview as the entry point · Elliptic, estimate of the stolen amount and attribution · Microsoft Learn, App Control for Business and AppLocker · Microsoft Learn, Software Restriction Policies · Microsoft Learn, file indicators in Defender for Endpoint