The compromised credentials behind the Binance theft likely carried elevated permissions, Art Gilliland, CEO of identity security company Delinea, said in a comment sent to CyberTech Edition on Nov. 1. Blockchain analytics firm TRM Labs puts the loss at about $6.36 billion and says the attacker could make Binance’s hot wallet signing system approve transactions of its choosing.

What Delinea’s Gilliland said

“The compromised credentials in the Binance breach likely had elevated permissions, otherwise the hackers would not have been able to extract over $6 billion,” Gilliland said. His point is that the size of a loss follows from what the stolen access was allowed to do. “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.”

He wants that to change how companies hand out permissions. Employees, service accounts and AI agents “shouldn’t have standing access to powerful permissions,” he said. “Give them access when they need it and remove it when the job is done.”

Advertisement

CyberTech Your brand belongs here. Reach the decision-makers who read CyberTech every day. Premium placements across the site and newsletter. Advertise with us

His closing advice is to plan for the intrusion itself. “Always assume an attacker will find a way in, and plan to limit what they can do once there,” he said. “That can make the difference between a contained incident and a crisis for the whole business.”

Delinea sells privileged access management and identity security software, so time-limited access to powerful accounts is its market. Gilliland’s description of the credentials is his assessment. Binance had not published a root cause when TRM Labs released its analysis.

What TRM Labs found

TRM Labs published its analysis on Oct. 29, the day of the theft. “Valuing each transfer at the price of the asset at the moment it was taken, the total is approximately USD 6.36 billion,” the firm wrote, calling it “the largest crypto theft on record, about four times the USD 1.5 billion Bybit hack of February 2025.”

The firm’s assessment is that “the attacker gained the ability to make Binance’s hot wallet signing system sign transactions of its choosing” across several blockchains. That is the access question Gilliland raises: whoever controls what a signing system will approve controls the funds behind it, whether or not a private key ever leaves the vault.

TRM attributes the attack to TraderTraitor, a North Korean hacking unit, and says: “We make this judgment with high confidence.” It counted “about USD 2.7 billion frozen onchain as of 00:30 UTC” the following morning. It also noted that “Binance has yet to publish a root cause.”

Newsletter

Get the week's best tech coverage.

Free. Read by thousands of HR, tech, and business leaders.

A pattern CyberTech Edition has covered before

Binance follows a smaller case from September, when Bitget lost $351.6 million from a hot wallet without anyone stealing a key.

The same lesson shows up outside crypto. A leaked secret for one cloud identity was enough to erase an entire tenant in the case covered in A Leaked GitHub Secret Erased an Azure Tenant, and in October Delinea’s Spencer Young made the related argument that teams should check for stolen credentials after patching PHP.

What it means for the security leader

In our reading, the useful question after Binance is which accounts and systems in your own estate can approve the movement of money or data on their own. Payment release, treasury transfers, code signing and production deploy pipelines all have an approval path. If an account on that path holds the permission permanently, its credentials are worth the full value of what it can approve.

Gilliland names three kinds of holder: employees, service accounts and AI agents. The second and third act without a person at the keyboard, so an access review that only covers staff accounts misses them.

What to do this week

  • List every human, service and agent identity that can approve or sign a transfer of funds, a code release or a bulk data export.
  • For each one, record whether the permission is permanent or granted per task. Move the permanent ones to time-limited grants with an approval step where the tooling allows it.
  • Check that signing and approval systems enforce their own limits, such as per-transaction caps and allow-listed destinations, so that a compromised caller cannot approve anything it asks for.
  • Run a tabletop that starts from a stolen engineer credential and ends at your largest single transfer, and note where the path could have been stopped.

Source: TRM Labs, North Korea steals USD 6.36 billion from Binance in the largest hack in history