Ở [bài đầu tiên]({{< relref "su-co-vi-nong-binance.md" >}}), các con số về vụ Binance còn rất mù mờ: từ hơn 3 tỷ USD trên Ethereum tới 5,6 tỷ USD nếu tính cả Bitcoin và Tron, trong khi sàn chưa xác nhận con số nào. Sau hai thông báo chính thức, bức tranh đã rõ hơn. Bài này trả lời hai câu hỏi: rốt cuộc mất bao nhiêu, ai chịu; và nếu Binance nói chưa thấy bằng chứng khóa riêng bị lộ, thì các chữ ký đã cho phép tài sản rời ví có thể được tạo ra bằng cách nào.

Đây là một khung để đọc thông tin, không phải kết luận về nguyên nhân. Báo cáo kỹ thuật của Binance chưa được công bố, và một số nhận định dưới đây có thể phải điều chỉnh khi có thêm dữ kiện. Thông tin chốt lúc 10:45 ngày 31/10/2026, giờ Việt Nam.

## Tóm lại: mất bao nhiêu, phong tỏa bao nhiêu, ai chịu

| Hạng mục | Con số | Nguồn |
|---|---|---|
| Tài sản bị ảnh hưởng | Khoảng 6,3 tỷ USD, trên nhiều chuỗi | Binance[^tb1][^tb2] |
| Đã bị phong tỏa trên chuỗi | Khoảng 3 tỷ USD, chưa phải đã thu hồi | Binance[^tb2] |
| Vốn Binance dành để bù | Hơn 6,34 tỷ USD, trong đó khoảng 5 tỷ USD đã có sẵn đúng các token bị lấy, phần còn lại đang mua | Binance[^tb2] |
| Phần người dùng phải chịu | Không có, theo cam kết của Binance | Binance[^tb2] |

{{< diagram "khong-lo-khoa-rieng-binance/con-so-xac-nhan" "Ba con số Binance đã công bố: khoảng 6,3 tỷ USD bị ảnh hưởng, khoảng 3 tỷ USD bị phong tỏa, hơn 6,34 tỷ USD vốn công ty dành để bù. Theo thông báo của Binance ngày 30–31/10/2026." >}}

Con số 6,3 tỷ USD của Binance khớp với ước tính độc lập của TRM Labs, khoảng 6,36 tỷ USD rời ví Binance trên mười mạng.[^trm] Điều đó cũng có nghĩa phần tiền rời ví trên Bitcoin và Tron, mà bài đầu tiên còn để ngỏ khả năng là điều chuyển nội bộ, nhiều khả năng đã thuộc về vụ tấn công.

Vậy người dùng Binance có mất tiền không? Theo Binance, câu trả lời là không. Ông Richard Teng nói vụ tấn công nhắm vào ví nóng của chính sàn, và Binance cam kết chịu toàn bộ thiệt hại bằng quỹ SAFU và vốn công ty, không để người dùng gánh.[^teng][^tb2] Nói cách khác, số dư của người dùng không bị trừ; Binance chịu 100%.

Ba điểm nên giữ trong đầu khi đọc các con số này. Thứ nhất, đây là cam kết, sẽ được kiểm chứng qua báo cáo bằng chứng dự trữ (Proof of Reserves) Binance hẹn công bố trước thứ Hai 02/11 và qua việc rút tiền mở lại theo từng giai đoạn, dự kiến trong khoảng 34 giờ kể từ thông báo số 2. Đến lúc chốt bài, cả hai vẫn là kế hoạch. Thứ hai, 3 tỷ USD bị phong tỏa chưa phải 3 tỷ USD đã về tay Binance, nên tôi chưa lấy 6,3 trừ 3 để gọi đó là thiệt hại ròng. Thứ ba, bù đủ tiền và khắc phục được nguyên nhân là hai việc khác nhau. Phần còn lại của bài nói về việc thứ hai.

## Binance đã giải thích gì về nguyên nhân

Thông báo đầu tiên, đăng sáng 30/10 giờ Việt Nam, cho biết sự cố có thể liên quan tới laptop bị xâm nhập của một kỹ sư DevOps, từ đó kẻ tấn công vào được một container dịch vụ và gửi các giao dịch rút tiền trái phép. Binance nói chưa tìm thấy bằng chứng khóa riêng của ví bị lộ.[^tb1] Tối cùng ngày, ông Teng bổ sung: điều tra đã phát hiện thêm các điểm xâm nhập, kẻ tấn công dùng một "cơ chế tự hủy" để xóa công cụ và dấu vết, và ủy quyền EIP-7702 đối với ví nóng không đi qua các kiểm soát phê duyệt thông thường của sàn.[^teng] Thông báo số 2 nhắc lại rằng chưa có bằng chứng lộ khóa và hẹn công bố thêm phát hiện kỹ thuật khi việc đó không ảnh hưởng tới điều tra.[^tb2]

Binance chưa nói laptop bị xâm nhập bằng cách nào, nên các giả thuyết về thư lừa đảo, phần mềm giả hay nội gián, theo tôi, nên được xem là phỏng đoán. Sự dè dặt này có thể có lý do chính đáng: công bố quá sớm có thể giúp kẻ tấn công. Theo tường thuật, ông Teng gọi EIP-7702 là giao thức đa chữ ký; có thể đó là cách nói rút gọn. Về kỹ thuật, EIP-7702 là cơ chế cho phép một tài khoản thường ủy quyền thực thi mã của một hợp đồng thông minh, không phải cơ chế nhiều chữ ký.[^eip]

## Giữ khóa và kiểm soát quyền ký có thể là hai việc khác nhau

Nhìn chung, một chữ ký trái ý chí chủ tài sản có thể ra đời theo ít nhất ba cách. Kẻ tấn công lấy được khóa và tự ký, như khi một ví cá nhân bị lộ cụm từ khôi phục. Kẻ tấn công điều khiển hoặc lợi dụng hệ thống ký mà không cần lấy khóa ra, như Bitget công bố về vụ tháng 9/2026. Hoặc người phê duyệt bị đánh lừa về nội dung thực sự được ký, như vụ Bybit năm 2025.[^cu] Đây là khung chung, không phải danh sách nguyên nhân đã xác nhận ở Binance, và một vụ việc có thể kết hợp nhiều cách.

Ở các tổ chức lưu ký lớn, khóa ví nóng thường được giữ trong thiết bị bảo mật phần cứng (HSM) hoặc chia mảnh qua tính toán đa bên (MPC), với thiết kế để khóa không rời khỏi đó. Nhưng thiết bị ấy vẫn phải ký rất nhiều lần mỗi ngày cho những yêu cầu được coi là hợp lệ. Nếu một yêu cầu đến từ đúng chỗ, hoặc lọt qua chính sách, thiết bị có thể vẫn ký, trong khi khóa chưa từng rời két. Tôi không biết Binance dùng kiến trúc nào; đoạn này chỉ mô tả cách các hệ thống như vậy thường vận hành.

Hình ảnh gần gũi là con dấu cơ quan: con dấu vẫn nằm trong két, nhưng nếu quy trình trình ký bị người khác điều khiển, văn bản trái phép vẫn có thể mang dấu thật. Phép so sánh có giới hạn: chữ ký trên chuỗi có hiệu lực ngay và khó hoàn tác, còn một phiếu ủy quyền EIP-7702 không tự hết hiệu lực mà giữ nguyên cho tới khi bị thay hoặc được đặt lại về địa chỉ rỗng.[^reset]

Vì vậy, theo tôi, câu "chưa tìm thấy bằng chứng lộ khóa" làm giảm khả năng của cách thứ nhất, nhưng chưa cho biết nhiều về hai cách còn lại. Nó cũng khác với khẳng định khóa chắc chắn an toàn, nhất là khi dấu vết đã bị xóa.

## Từ chiếc laptop tới chữ ký

DevOps là nhóm kỹ sư vận hành hệ thống; container là một môi trường đóng gói để chạy một dịch vụ, tách khỏi các dịch vụ khác. Laptop của một kỹ sư DevOps vì thế có thể là điểm truy cập có giá trị. Điều tôi quan tâm hơn là quãng đường từ chiếc laptop tới chữ ký.

{{< diagram "khong-lo-khoa-rieng-binance/duong-di-chu-ky" "Mô hình khái niệm năm chặng của một lệnh rút tiền, không phải kiến trúc của Binance. Các ghi chú dưới mỗi chặng lấy từ thông báo của Binance và phát biểu của Richard Teng ngày 30/10/2026." >}}

Đặt các phát biểu của Binance lên mô hình này, kẻ tấn công có vẻ đã vào ở chặng container, còn ủy quyền EIP-7702 không đi qua chặng phê duyệt. Điều chưa được giải thích là yêu cầu đã tới chặng ký bằng cách nào: lớp phê duyệt bị vượt qua, bị vô hiệu, hay ngay từ đầu không được thiết kế để nhận diện một phiếu ủy quyền EIP-7702. Khả năng cuối khiến tôi suy nghĩ nhiều hơn cả, vì phiếu ủy quyền là một loại thông điệp riêng, được băm với tiền tố 0x05, khác hẳn giao dịch rút tiền.[^eip] Đây chỉ là suy luận của tôi; Binance chưa nói điều này.

## Dữ liệu trên chuỗi cho thấy gì, và chưa cho thấy gì

Hai bài trước đã ghi nhận Binance 14 bị ủy quyền cho [hợp đồng quét]({{< relref "hop-dong-quet-vi-nong-binance.md" >}}), Binance 16 tự ký chuyển tiền, Hot Wallet 34 bị rút qua Binance 14, và Binance 14 vẫn được nạp thêm tiền khi đang bị chiếm quyền. Khi viết bài này, tôi kiểm lại giao dịch ủy quyền: 50 phiếu với nonce liên tiếp từ 18.914.775 đến 18.914.824; khôi phục người ký của ba phiếu ở đầu dải, cuối dải và phiếu đã có hiệu lực đều ra Binance 14. Giao dịch của Binance 16 là giao dịch thông thường do chính ví này gửi.[^onchain]

Nguồn mới là TRM Labs: cùng đêm đó, các ví Binance trên XRP Ledger, Bitcoin, Tron, Solana và năm mạng khác cũng gửi tiền cho kẻ tấn công bằng giao dịch ký thông thường, với các loại khóa và cơ chế ký khác nhau. Lượt rút đầu tiên, trên XRP Ledger, diễn ra khoảng mười lăm phút trước giao dịch ủy quyền trên Ethereum.[^trm] Nếu số liệu này được xác nhận, EIP-7702 có lẽ chỉ là một trong nhiều con đường. Bức tranh ấy có vẻ gần với cách thứ hai hơn cách thứ nhất, vì việc trích xuất cùng lúc khóa của nhiều hệ ký khác nhau là khó hình dung, dù không thể loại trừ. TRM cũng đánh giá khả năng cao nhất là hệ thống ký ví nóng của Binance đã bị điều khiển; đó là đánh giá của một hãng phân tích, chưa phải kết luận điều tra.

Một số điều dữ liệu trên chuỗi khó trả lời. Nonce là số thứ tự giao dịch, không phải dấu thời gian, nên dải 50 nonce cho thấy người chuẩn bị đã ước tính đúng nonce quanh thời điểm thực thi, nhưng chưa chứng minh chữ ký được tạo sát giờ gửi. Cũng chưa thể nói hệ thống ký ký được mọi loại thông điệp, mới chỉ thấy nó đã ký phiếu ủy quyền và giao dịch chuyển tiền. Ai đã yêu cầu ký, và vì sao việc nạp tiền vào Binance 14 chưa được dừng sớm hơn, nhiều khả năng cần đến nhật ký nội bộ.

## Những câu hỏi còn mở

Khi Binance công bố báo cáo kỹ thuật, tôi sẽ tìm câu trả lời cho mấy câu hỏi: yêu cầu ký đi từ container tới hệ thống ký qua kênh nào; lớp phê duyệt xử lý phiếu ủy quyền EIP-7702 ra sao; các điểm xâm nhập mới nằm ở đâu; và sau khi dấu vết bị xóa, nhật ký nào còn đủ để dựng lại chuỗi sự kiện. Tôi cũng không chắc báo cáo công khai sẽ trả lời hết, vì có những chi tiết công bố ra có thể giúp kẻ tấn công lần sau.

Về thủ phạm, TRM quy cho nhóm TraderTraitor của Triều Tiên với độ tin cậy cao, và Chainalysis cũng nghiêng về hướng này.[^quyket] Đến lúc chốt bài, tôi chưa thấy cơ quan điều tra nào công bố quy kết, và Binance cũng chưa.

## Tới đây chúng ta rút ra được gì

Về tiền, câu trả lời đã khá rõ. Theo cam kết của Binance, người dùng không phải gánh phần nào trong khoảng 6,3 tỷ USD bị ảnh hưởng. Từ nay tới thứ Hai 02/11, chúng ta có hai mốc để tự kiểm chứng điều đó: rút tiền có mở lại như hẹn không, và báo cáo dự trữ cho thấy những gì.

Về nguyên nhân, câu chuyện mới chỉ bắt đầu. "Chưa thấy lộ khóa" không có nghĩa là không có gì hỏng. Có lẽ chúng ta nên quen nhìn an toàn của khóa và an toàn của quyền ký như hai câu hỏi riêng. HSM hay MPC giúp trả lời câu hỏi khóa có bị lấy mất không, còn câu hỏi ai được yêu cầu khóa ký cái gì cần đến những lớp kiểm soát khác.

Và còn vài câu hỏi tôi nghĩ chúng ta nên cùng bàn tiếp. Ranh giới giữa tiện ích và rủi ro của EIP-7702 nên được vạch ở tầng giao thức, tầng ví hay chính sách của từng tổ chức? Một sàn nên công khai bao nhiêu về kiến trúc ký của mình? Và khi một sàn đủ lớn để tự bù 6 tỷ USD, điều đó khiến thị trường an tâm hơn, hay khiến chúng ta dễ bỏ qua câu hỏi về nguyên nhân? Tôi rất muốn nghe thêm góc nhìn của bạn đọc.

[^tb1]: [Security Incident Update (2026-10-30)](https://www.binance.com/en/support/announcement/detail/c5a8729a97ac486d963784d96c5642d7), thông báo của Binance đăng 02:23 UTC ngày 30/10/2026, cập nhật 11:36 UTC cùng ngày.
[^tb2]: [Security Incident Update #2 (2026-10-30)](https://www.binance.com/en/support/announcement/detail/d3306d9dca5243548c813b605e1d1751), thông báo của hai đồng CEO Yi He và Richard Teng, đăng 19:33 UTC ngày 30/10/2026.
[^teng]: Video của Richard Teng đăng trên X ngày 30/10/2026, theo tường thuật của [Decrypt](https://decrypt.co/382237/binance-sets-aside-6-34b-to-cover-hack-losses-ceo-says-your-assets-are-safe) và [Bitcoin.com News](https://news.bitcoin.com/security/new-breach-points-binance-ceo-reveals-fresh-findings-6-3b-hack/), 30/10/2026.
[^trm]: TRM Labs, [North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History](https://www.trmlabs.com/resources/blog/north-korea-steals-usd-6-36-billion-from-binance-in-the-largest-hack-in-history), 29/10/2026; số liệu tới 00:30 UTC ngày 30/10/2026.
[^eip]: Theo [đặc tả EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) (trạng thái Final), phiếu ủy quyền là chữ ký trên keccak(0x05 ‖ rlp([chain_id, address, nonce])), chỉ hợp lệ khi nonce trong phiếu bằng nonce hiện tại của tài khoản ký.
[^cu]: Nguồn về Bitget và Bybit nằm trong bảng so sánh ở bài [CZ tuyên bố Binance bị tấn công]({{< relref "su-co-vi-nong-binance.md" >}}).
[^reset]: Theo [đặc tả EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), mã ủy quyền được ghi lâu dài vào tài khoản; một ủy quyền mới trỏ về địa chỉ 0x0 sẽ xóa mã ủy quyền này.
[^onchain]: Giao dịch ủy quyền [0xad99264d…](https://etherscan.io/tx/0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b) (khối 26.300.753) và giao dịch của Binance 16 [0x51f263fa…](https://etherscan.io/tx/0x51f263fa50966df6bbd7f8c6e6e99e3791c94444f7c4343b2fef1ee2d62fd39f), đối chiếu qua Etherscan ngày 31/10/2026.
[^quyket]: TRM Labs quy kết với độ tin cậy cao trong bài đã dẫn; về đánh giá của Chainalysis, theo [Bitcoin.com News](https://news.bitcoin.com/security/binance-hackers-deploy-never-seen-before-crypto-laundering-tactics/), 30/10/2026.