top of page
40051abd5a76713af8f015988fc6780e-blue-phone-icon-with-a-wave-on-it.webp
Logo-Zalo-Arc.webp
Facebook_Messenger_logo_2020.svg.webp
whatsapp

Binance hack explained: From fake interviews to wallet access

5 days ago
6 min read

Binance’s preliminary investigation, published on November 3, 2026, provides new details about the attack on its wallet infrastructure. Understanding the incident requires looking at the path from employee devices to sensitive systems, as well as the controls needed to interrupt that path. [1]

IPSIP’s earlier coverage of the Binance security incident documented the initial developments. This follow-up examines the reported attack sequence and the practical lessons for access control. The earlier article is available in Vietnamese.

For organizations, the central question is straightforward: if an employee runs untrusted code, which systems could that code reach, and what would stop it from moving further?

What the preliminary investigation reveals?

According to Binance, the campaign involved a tampered Homebrew installation in June, a fake interview and malicious coding assignment in September, abuse of an internal AI tool on October 20, and stolen credentials used to deploy a container on October 29. Malware replaced a pyenv component. The attackers subsequently reached wallet signing operations and abused EIP-7702 authorization. Suspending withdrawals did not invalidate existing on-chain permissions.

On October 31, the FBI attributed the theft of more than $6 billion to North Korean cyber activity it calls TraderTraitor. That attribution should be distinguished from the technical findings published by Binance.

nguyen-nhan-binance-bi-hack-bay-tuyen-dung
Binance hack causes

How a coding assessment becomes an entry point?

Technical recruitment creates a setting in which downloading code, installing dependencies, and running unfamiliar applications can appear routine. When these requests follow professional conversations and several interview stages, candidates may become less inclined to question them.

A convincing video call or an established social media profile provides an identity signal. It does not establish that the person represents the claimed employer or that the repository they supplied is safe to execute.

IPSIP has previously covered recruitment scams impersonating major brands in Vietnamese. For developers, an additional question matters: does the proposed testing environment contain active work sessions, internal source code, or access to production systems?

Microsoft has also documented Contagious Interview, a campaign that uses recruitment and technical assessments to deliver malware. This research provides relevant context for recognizing the tactic; similarities alone do not establish that separate incidents belong to the same campaign.

Treat developer workstations as important access points

A developer workstation may support coding, testing, service administration, and access to cloud platforms. Combining these activities in one environment can expose several resources when untrusted code runs.

pyenv manages Python versions. More generally, replacing a familiar development component creates a software integrity problem: the command a user recognizes can remain the same while the component it executes has changed. A familiar filename is therefore insufficient evidence that a tool is trustworthy.

Organizations should map access from developer devices. Which secrets are available? Which services can the device reach? Which sensitive actions require additional approval? Those answers help define the potential impact of a compromised endpoint.

Binance-hack-causes
Binance haccauses

Three control boundaries worth reassessing

The following points are IPSIP’s defensive analysis of the public reporting, rather than findings from an independent audit of Binance.

  1. The boundary between external code and the work environment. Coding assessments, open-source experiments, and unfamiliar tools need an appropriate execution environment. Its design should prevent a compromise from inheriting the user’s work sessions or deployment privileges.

  2. The relationship between internal tools and execution privileges. When assessing an AI tool, review the data it can read, the services it can invoke, and the actions that require approval. AI functionality does not remove the need for access controls and audit trails.

  3. The ability to revoke access during an incident. Teams need to know which permissions end when an account is disabled, which require separate revocation, and which operations can continue after a service stops. Exercises should measure both detection time and the time needed to disable dangerous permissions.

Recovery updates: freezing assets is different from recovering them

Binance reported approximately $6.34 billion in affected assets and about $2.85 billion frozen or intercepted at the time of its update. Its findings remain preliminary.

In its October 30 announcement, Binance said it had found no evidence of wallet private keys being leaked. That statement must be read within the scope and timing of the investigation; it does not establish that the wider signing process was secure.

The November 3 recovery announcement described the progressive reopening of withdrawals for additional assets and networks after security checks. It did not mean that withdrawals for every asset became available simultaneously.

When reporting recovery progress, distinguish between assets blocked from further movement, assets actually recovered, and assets replaced using the company’s own resources. These describe different parts of remediation and should not be treated as interchangeable outcomes.

What organizations can do in practice?

Effective safeguards need an owner, a way to identify problems, and an agreed response. The following implementation priorities are IPSIP’s recommendations, informed by the incident and guidance from Microsoft and Atlassian.

1. Manage and monitor work devices

Maintain an endpoint inventory, manage patches and approved software, and review local administrator privileges. Separate experimental development environments from those with production access.

Endpoint detection and response (EDR) or extended detection and response (XDR) can support investigation of suspicious activity. Useful signals include unexpected shells launched by development tools, processes accessing credential stores before making outbound connections, and development components modified outside approved workflows. Interpret these events in the context of legitimate work.

Make monitoring transparent and focused on security events involving work devices and accounts. Restrict access to collected logs. Assign responsibility for reviewing the results and acting on alerts.

2. Reduce the credentials and privileges available from each endpoint

Review the accounts, tokens, and active sessions accessible from each workstation. Prioritize least privilege, short-lived credentials, and access granted when needed. Sensitive operations should involve independent approval. Include the connections available to internal AI tools in the same access review.

An effective review should produce an actionable record of access owners, approved purposes, and revocation procedures. It should also identify permissions that can be removed without disrupting necessary work.

3. Organize round-the-clock monitoring and response according to risk

For financial infrastructure and continuously operating services, IPSIP recommends considering an internal, outsourced, or hybrid security operations center (SOC) that can validate and escalate alerts outside business hours.

Agree on:

  • Which endpoint, identity, and critical-service logs are collected.

  • Who receives alerts and the expected validation and notification times.

  • Who can isolate devices, disable accounts, or revoke tokens.

  • When incidents must be escalated to operations teams and leadership.

Continuous monitoring needs an operational response behind it. Software running around the clock does not, by itself, establish that an alert will be investigated or contained.

4. Train staff using realistic scenarios and reporting exercises

Include fake coding tests, fraudulent meeting applications, and malware delivered through recruitment materials in awareness activities. The linked IPSIP article is in Vietnamese.

Employees should practice verifying suspicious requests and reporting situations in which they have already opened a file or run a command. IPSIP recommends assessing recognition, reporting time, and the support team’s response alongside training completion rates.

The reporting route should be easy to find and use. Employees need to know whom to contact and what information to preserve, including when a suspicious interaction happens outside normal working hours.

5. Use ISO/IEC 27001 to sustain the management process

iso-27001-2022
Implement management according to ISO 27001:2022 standards.

ISO/IEC 27001:2022 sets requirements for an information security management system, with risk assessment, risk treatment, and continual improvement at its core. ISO/IEC 27002:2022 provides guidance on information security controls.

Organizations can use this framework to assign responsibilities, select appropriate controls, retain evidence of operation, and address weaknesses. It should not be presented as requiring every organization to buy the same tools or adopt an identical SOC model. Controls should reflect risk, and certification is not a guarantee that attacks will never occur.

For this scenario, a useful management outcome is clear ownership of developer endpoint security, a documented response process, and evidence that those arrangements are reviewed and exercised.

What individuals should do when approached by a recruiter?

The FBI identifies requests to run code or install software for interviews as potential indicators of malicious activity. Before proceeding:

  • Verify through an independent channel. Find an official company contact yourself and confirm the approach. Do not rely solely on profiles or links supplied by the person contacting you.

  • Keep unfamiliar code away from work devices. If execution is necessary, use a suitably isolated environment that has no corporate network connection, work accounts, or work secrets.

  • Pause when the process becomes unusual. Do not disable security protections or run commands to “fix” a camera or interview application at an unverified person’s request.

If you have already run a suspicious assessment

Disconnect the device from the network and notify IT or security immediately. Preserve the repository URL, messages, and commands you ran. From a known-clean device, coordinate session revocation and replacement of potentially exposed credentials. Deleting the repository or completing one antivirus scan is insufficient to establish that the device is safe; investigation and remediation may include reimaging it.

Strengthen monitoring and response with IPSIP

For organizations seeking additional detection and response capacity, IPSIP’s 24/7 SOC service supports monitoring, alert validation, and coordinated incident handling within an agreed scope. The linked service page is in Vietnamese.

Start by identifying critical devices, reviewing access rights, and determining which logs are available. Then agree on response contacts and the authority to intervene when suspicious activity is detected.

-----------

Refferal

follow ipsip vietnam.png
bottom of page