Binance’s $6.3B incident: what happened and how to reduce the risk

Binance’s preliminary findings describe employee compromises in June and September, followed by a wider intrusion through internal AI tooling on 20 October. Attackers reached two colleagues’ computers and found a token for deploying containers. On 29 October, they used it to deploy malicious code that reached wallet signing systems and initiated unauthorized transfers.

The attackers also used the signing service to create an EIP-7702 delegation: permission for attacker-controlled code to act for an Ethereum wallet. That permission existed on the blockchain, independently of Binance’s withdrawal systems. Stopping withdrawals could not remove it. Binance needed a separate on-chain revocation.

The important distinction is between stopping an activity and removing the authority behind it. Replacing a device, revoking a deployment credential and cancelling a permission inside another system each address a different part of an intrusion.

A laptop, a deployment system and a sensitive service do different jobs. The risk grows when access to one automatically opens the next. A stolen token can let an attacker replace software. That software can then act with permissions the employee never had directly.

Four questions help identify where to interrupt that progression:

1. Credential exposure. What production access can an attacker obtain from one employee’s device?
2. Deployment privileges. Who can change the code that runs with that access?
3. Service authorization. Which actions will a sensitive service accept from that code?
4. Persistent access. What new permissions could remain after the original account is disabled?

The aim is to limit how authority passes between systems and to identify and revoke any additional access created during an intrusion. The following sections examine four controls that support that goal.

Control 1. Reduce the credentials a laptop can expose

A credential is useful to an attacker because another system accepts it as proof of authority. Keeping fewer production credentials on employee devices reduces what can be stolen when a tool, repository or browser session is compromised.

For routine work, an employee often needs permission to request an operation, such as restarting a service. The credential that performs it can stay with a separate execution identity. Reducing exposure then involves both removing unnecessary copies and managing the credentials that remain:

• Replace routine direct access with narrowly defined operations where practical.
• Use separate identities for separate duties and limit their scope and lifetime.
• Keep an inventory of credentials, their owners and how to revoke them.

This applies the principle in OWASP’s secret-management guidance: reduce human handling of secrets and grant only the access each identity needs. A stolen workstation then exposes fewer reusable credentials, and responders know who owns those that still need revoking.

Control 2. Treat deployment rights as production privileges

A secret can be hidden from a person but available to the code they deploy. Whoever can change that code may be able to read the secret, call an internal API or act as the application’s service account. Deployment access must therefore be assessed against the permissions of the resulting workload.

OWASP’s CI/CD security guidance treats repository changes, pipeline configuration and execution hosts as parts of the same security problem. Protection needs to cover the code before deployment and its permissions after deployment:

• Require review for production code and protect the repository branch that automation executes.
• Control changes to task definitions, dependencies and launch-time inputs as well as the main script.
• Give workloads only the credentials and network access needed for their function.

Two sets of controls must work together. Repository and deployment permissions determine who can change the code. Separate identity, host and network policies limit what that code can do once it runs. Central secret storage reduces exposure, while those policies constrain the program that uses the secret.

Control 3. Authorize the operation, not just the caller

A signing service can keep its private key hidden and still accept a harmful signing request. The same distinction applies to a database or cloud API: authenticating a workload identifies the caller, while authorization decides what it may do.

OWASP recommends checking authorization on every request and denying access unless it is explicitly allowed. At the receiving service, that means checking both the action and its target: permitted payment destinations and amounts, database operations or infrastructure changes.

The outcome should be a service that evaluates the requested action even when the caller is already trusted. Automation governs how work is requested. The receiving service governs which operations it will accept.

Control 4. Revoke access created during the intrusion

An attacker may use a legitimate identity to add another credential or grant further permissions. MITRE ATT&CK documents account manipulation as a way to preserve or increase access, including adding cloud credentials and SSH keys. Disabling the original session does not necessarily remove those changes.

Binance’s on-chain delegation illustrates why responders must inspect permissions in the affected system itself. Containment needs to cover both the initial foothold and the authority created through it:

• Limit which automation identities can create further credentials or grant permissions.
• Include newly created accounts, sessions and delegations in the response plan.
• Verify revocation at the system that enforces the permission, rather than treating a stopped task as proof of containment.

Following those steps gives responders a defined set of identities and permissions to investigate and revoke. It also makes containment testable: the team can check whether each known route into the affected service has actually closed.

These controls operate at different layers: the employee’s device, the deployment system, the receiving service and the response process. Each needs an owner and a way to verify that its restrictions hold when another layer is compromised.

Automation management platforms address the part of this problem between an employee’s request and production execution. In Semaphore UI, a team can prepare a defined task, control who may run or change it, and execute it with a separate identity. Authorization inside the target service and revocation of permissions created elsewhere remain the responsibility of those systems and the response team.

Consider an on-call engineer who needs to restart an API service. A maintainer prepares a playbook and a Task Template that fixes the target hosts and how the restart runs. The engineer starts the task and reads the result, without opening an SSH session to production. The two paths below perform the same restart but place the execution credential in different hands.

Building the restart workflow takes four connected steps: create a restricted execution identity, define what users may run or change, choose its execution environment, and make the result visible. Once those steps are in place, the same approach can be extended to deployments.

A stolen operator session can still request the operations that account is allowed to run. Even a permitted restart can disrupt a service if repeatedly triggered. Test the configured workflow with a realistic operator account in staging, covering both what it can do and how the team would respond to misuse:

• Task and input permissions. Try the actual roles and launch-time options, including alternative branches, inventories and arguments.
• Access beyond the intended operation. Check access to other templates, credentials and production systems, including what the runner’s process can reach.
• Detection and operational impact. Confirm who receives results, who investigates unexpected activity and whether repeated runs can cause unacceptable disruption.
• Revocation. Test session and token revocation, and identify any permissions the execution identity could create elsewhere.

Document the access the test account retains and close any route that exceeds the operation’s purpose. The team should finish the exercise knowing both what a stolen session could do and how to detect and contain that misuse.

Access controls work alongside endpoint protection and a team that knows how to respond. Make the prepared workflow convenient enough that people can use it without falling back to shared keys and undocumented shortcuts. Support it with a few everyday practices:

• Run unfamiliar installers and interview assignments in disposable, isolated environments without corporate credentials, host mounts or access to internal networks.
• Make suspicious activity easy to report early and without blame. Give people a clear contact and an incident-response path.
• Review access as duties change, maintain a controlled emergency-access procedure and rehearse revocation before an incident.

These practices connect prevention, detection and recovery to day-to-day work. They help keep the access model accurate as responsibilities change and give the team a familiar response when a suspicious event occurs.

The central lesson is to limit how much authority one compromised identity can accumulate. Fewer credentials on laptops, reviewed automation, restricted execution hosts and authorization inside production services each reduce the routes an attacker can take.

Semaphore makes several of those controls part of a repeatable workflow: prepared tasks, separate run and edit permissions, centrally supplied credentials and visible execution records. Operators get the actions their jobs require, while maintainers retain control over the code and credentials behind them.

Start with one frequently used production operation: prepare its task template, assign the necessary operator permissions, and test the resulting access before retiring the direct connection it replaces. The useful measure of progress is how little an attacker can do with the next account they compromise.