Cybersecurity industry leaders in APAC chime in on lessons learnt from the US$6.36 billion theft.
Late last week, the FBI and blockchain intelligence firms, including TRM Labs and Chainalysis, attributed the Binance hack to North Korean state-backed actors.
Reports so far suggest that the attackers got in through a compromised DevOps engineer’s laptop, then subverted signing processes across 10 blockchains to move funds out in minutes.
Cybersecurity leaders in APAC share their thoughts and lessons learnt from this breach.
Evgeniy Yanov, Head of Audit and Consulting Department, F6:
The attack vector employed by the hackers in the Binance incident is nothing new. It follows one of the most well-established scenarios: the attack does not begin on the blockchain itself, but rather at the workstation of an employee with access to critical infrastructure.
For example, in a 2022 incident involving Sky Mavis, an employee was lured by a fake job offer containing a malicious document — the attackers gained control over the majority of the Ronin network’s validator keys and stole approximately $600 million. In 2024, an employee at a DMM Bitcoin contractor fell for a fake recruiter on social media, resulting in a $300 million loss. And in 2025, the compromise of a developer’s machine at a third-party wallet service provider enabled interface spoofing, effectively tricking Bybit into transferring $1.5 billion to the attackers.
In broad terms, the mechanics of the recent Binance breach mirror the Bybit incident. In both cases, the target was not the blockchain itself, but rather an individual or a process involved in the transaction-signing workflow.
However, there is a fundamental difference. In the Bybit case, the wallet developer’s system was compromised, and the authorized signers were deceived — they saw a fraudulent interface and personally approved a malicious transaction. In the Binance incident, according to the company, the attack was carried out via a service container — an automated fund-withdrawal system.
The platform Blockaid highlights an even more unique element: a batch of 50 EIP-7702 authorizations within a single transaction, combined with the delegation of an account to a malicious “sweeper” contract. This specific mechanism has not been seen before in large-scale breaches of this size.
This explains why multi-signature schemes and “cold” wallets failed to protect the assets. Multi-signature schemes protect against the theft of an individual key, but they are ineffective if the signing management process itself is compromised.
If an attacker has already infiltrated the environment where transactions are approved, the required quorum can be reached in a way that appears entirely legitimate. In the case of “cold” wallets, exchanges need to process frequent withdrawals; consequently, an automated process must exist to bridge the gap between offline keys and the blockchain — and it is precisely this process that becomes the primary target.
This incident highlights a concerning trend: leaks of keys and tokens frequently lead to major security breaches — a problem that has only intensified with the proliferation of AI. Malicious software has long targeted SSH keys, cloud credentials, and environment (.env) files on developers’ machines. AI agents with access to the file system further expand the attack surface, inadvertently aiding attackers in their efforts.
Raghu Nandakumara, Vice President of Industry Strategy, Illumio:
Strip away the record-breaking number, and the attack itself looks depressingly familiar. According to early reports, an engineer was talked into taking a ‘test’, and malware landed on their laptop while they did it. That laptop was already authenticated and already privileged, so it became the attacker’s route straight into production, and from there to the wallets.
None of those steps is new. What should concern every security leader is how rarely the attacker had to prove who they were. Once they had the laptop, every step after it relied on trust that was assumed instead of checked.
To be fair to Binance, nobody stops every social engineering lure, and the post-mortem isn’t out yet. But you don’t have to prevent the first click to limit what it costs you. How far one compromised device can reach is an architectural decision, and it was made long before this attack.
Until organizations make Zero Trust a core part of their security programme, and aggressively remove implicit, excessive access across identities, networks and data, starting with their most privileged users, we’ll keep reading this story. So here’s a question for every team this week: if your most privileged engineer’s laptop were compromised tonight, what could it reach?
Art Gilliand, CEO, Delinea:
The compromised credentials in the Binance breach likely had elevated permissions, otherwise the hackers would not have been able to extract over $6 billion. Once attackers get inside an organization, the damage they can make depends on what they’re able to access and what that access allows them to do.
The flood of incidents in the past month should push every business leader to look closely at their access controls. Employees, service accounts and increasingly AI agents shouldn’t have standing access to powerful permissions sitting. Give them access when they need it and remove it when the job is done.
Always assume an attacker will find a way in, and plan to limit what they can do once there. That can make the difference between a contained incident and a crisis for the whole business.
Javvad Malik, Lead CISO Advisor, KnowBe4:
The Binance incident yet again shows the most catastrophic breaches rarely exploit exotic zero-days in core protocols but instead hinge on privileged access failures. In plain terms, the breach reportedly began when attackers compromised an engineer’s laptop, which served as a stepping stone into internal infrastructure.
For company leaders, the lesson is straightforward: trusting your outer perimeter is no longer enough, and no single worker or machine should ever hold the keys to the entire kingdom.
Leaders need to build walls between everyday work laptops and core financial systems, require multiple independent people to sign off before large amounts of money can leave the building, and set automatic spending caps that immediately freeze suspicious, high-volume transactions before the damage is done.
Justin Moore, Director of Adversary Operations, Arctic Wolf:
Early reporting on the Binance incident from TRM Labs points to the TraderTraitor group, a DPRK hacking unit, who was able to compromise an engineer’s laptop, allowing adversaries access to the systems that approve withdrawals.
If the emerging attribution is correct, it represents a major escalation in a North Korean campaign that has been operating for close to a decade. DPRK-linked actors were estimated to have stolen roughly $6.75 billion cumulatively through 2025, including more than $2 billion during 2025 alone. A $6.36 billion theft from Binance would nearly match that prior cumulative total in a single operation.
North Korea’s cryptocurrency operations have evolved from repeated attacks against exchanges and digital-asset projects into an industrial-scale revenue model. Rather than relying on one type of exploit, these operators target developers, employees, signing systems and third-party infrastructure, looking for the point where trusted access can be converted into an authorized transfer.
The defining feature of the Binance incident is the apparent subversion of trusted withdrawal and signing processes across several blockchains. This was potentially less like stealing the key to a vault and more like compromising the process that tells the vault which requests to approve.
Security teams should focus on limiting what any one system or person can do:
- Privileged endpoints should be treated as high-value targets, with tighter monitoring and stronger isolation.
- Independent approval for high-impact actions, like moving funds or changing keys should be implemented so one compromised account cannot execute an entire attack chain alone.
- Signing and key management should be kept separate from everyday work environments as security teams strictly monitor administrator and engineering accounts on a 24×7 basis.
