Mổ xẻ hợp đồng đã quét ví nóng Binance, hay vụ hack đã được cảnh báo trước

Trong bài CZ tuyên bố Binance bị tấn công, tôi đã nêu diễn biến và các con số của vụ hơn 3 tỷ USD rời ví nóng Binance rạng sáng 30/10/2026. Bài này đi vào một chi tiết kỹ thuật nằm ở giữa vụ việc: hợp đồng thông minh mà kẻ tấn công dùng để quét ví, địa chỉ 0x63e8…6fae.¹

Điều đáng nói là kịch bản này không hề mới. Ngày 1/6/2025, chưa đầy một tháng sau khi EIP-7702 được kích hoạt trên mạng chính Ethereum cùng bản nâng cấp Pectra, hãng tạo lập thị trường Wintermute đã cảnh báo công khai: phần lớn các ủy quyền EIP-7702 khi đó trỏ về những bản sao của cùng một hợp đồng, được viết để tự động vét sạch ví bị lộ khóa ngay khi có tiền vào. Họ đặt tên cho nó là CrimeEnjoyor.² Bản thân đặc tả EIP-7702 cũng viết thẳng rằng mã được ủy quyền “có quyền truy cập không giới hạn vào tài khoản”, và “không có cách nào an toàn” để một ví cho phép ký ủy quyền tùy ý.³

Hợp đồng quét ví Binance 14 là phiên bản quy mô lớn của đúng kịch bản đã được cảnh báo: ủy quyền cho một hợp đồng quét, rồi vét toàn bộ ETH và token trong một giao dịch. Cần nói cho công bằng, các cảnh báo ấy nhắm vào một lớp rủi ro chung chứ không dự báo riêng về Binance, và EIP-7702 không tự làm lộ khóa. Như chuyên gia bảo mật Taylor Monahan nhận xét lúc đó, nó chỉ làm việc vét ví rẻ và nhanh hơn cho kẻ đã nắm được khóa.² Với một ví nóng giữ hàng tỷ USD, “nhanh hơn” nghĩa là một khóa bị lộ có thể bị khai thác gần như trọn vẹn chỉ trong một giao dịch.

Lý do đáng mổ xẻ nó rất đơn giản. Mọi lời giải thích về vụ việc, dù là lộ khóa, hệ thống ký bị thao túng hay nội gián, cuối cùng đều phải khớp với những gì hợp đồng này làm trên chuỗi. Và trên chuỗi thì không có gì bị xóa.

Địa chỉ các ví và giao dịch chính lấy từ truy vết của ChainTracer.⁴ Phần phân tích bytecode, khôi phục chữ ký và đối chiếu nonce dưới đây là do tôi tự kiểm lại từ dữ liệu công khai trên Ethereum. Nhận định trong bài là quan điểm cá nhân.

Một tệp mã 1.674 byte

Hợp đồng quét chỉ có 1.674 byte mã chạy (runtime bytecode), tương đương khoảng một trăm dòng Solidity. Nó không có biến lưu trữ, không có chủ sở hữu thay đổi được, không có cơ chế nâng cấp. Toàn bộ quyền điều khiển nằm trong một hằng số khắc cứng vào mã: địa chỉ ví khởi phát 0x7c86…5ca0. Mọi hàm quan trọng đều kiểm tra người gọi có phải ví này không, nếu không thì dừng với lỗi NotAuthorized.

Trên Etherscan, hợp đồng này đang hiển thị mã nguồn “đã xác minh”. Cần đọc kỹ: phần chú thích đầu tệp ghi rõ đây là mã do một mô hình AI dựng lại từ bytecode, không phải mã gốc của kẻ tấn công.⁵ Tôi không dùng nguyên văn bản dựng lại mà biên dịch lại nó bằng solc 0.8.28 với đúng cấu hình ghi kèm. Kết quả trùng từng byte với mã đang chạy trên chuỗi, chỉ khác đoạn metadata cuối tệp. Vì vậy logic mô tả dưới đây là chắc chắn; tên biến bên trong là phỏng đoán, còn tên hàm khớp với mã hàm 4 byte trên chuỗi.

Không phải một két sắt, mà là một bộ não thay thế

Điểm khác thường nhất của hợp đồng này là nó không giữ tiền và không được gọi trực tiếp. Nó được thiết kế để chạy như mã của chính ví nạn nhân, thông qua EIP-7702.⁶

Với EIP-7702, chủ một ví thông thường có thể ký một “phiếu ủy quyền” nói rằng: từ nay, khi ai đó gọi vào địa chỉ của tôi, hãy chạy mã của hợp đồng X. Sau khi phiếu được đưa lên chuỗi, địa chỉ Binance 14 vẫn là địa chỉ cũ, số dư vẫn nằm đó, nhưng mã chạy tại địa chỉ ấy là mã của hợp đồng quét. Khi ví khởi phát gọi sweep vào địa chỉ Binance 14, câu lệnh balanceOf(address(this)) hỏi số dư của chính Binance 14, và lệnh transfer được các hợp đồng token hiểu là Binance 14 tự chuyển tiền đi.

Đây là lý do tôi gọi hợp đồng này là bộ não thay thế. Kẻ tấn công không cần lấy trộm từng khoản tiền. Họ cần đúng một chữ ký hợp lệ để thay bộ não của ví, sau đó ví tự làm theo lệnh của họ với bất kỳ tài sản nào đang có hoặc sẽ được nạp vào.

Nếu đặt vào một ngân hàng

Với người quen nghiệp vụ ngân hàng hơn là Solidity, mỗi thành phần của bộ não này đều có một hình ảnh tương đương khá sát. Điểm khác nằm ở cột thứ ba, và chính các điểm khác đó làm nên vụ việc.

Ghép lại, vụ việc tương đương một tình huống như sau ở ngân hàng. Ai đó có được chữ ký hợp lệ của giám đốc tài chính một doanh nghiệp. Họ nộp giấy ủy quyền toàn quyền cho một người lạ, kèm yêu cầu cài lệnh quét toàn bộ số dư, mọi loại tiền, về một tài khoản ở nơi khác. Ngân hàng chấp nhận vì chữ ký đúng mẫu. Từ đó, mỗi lần người lạ gọi một cuộc điện thoại, toàn bộ số dư bị chuyển đi, kể cả khoản tiền khách hàng vừa nộp vào lúc trước. Và vì doanh nghiệp này còn dùng tài khoản ấy để điều hành một tài khoản con, người lạ ra lệnh chi luôn từ tài khoản con.

Ở ngân hàng, một giấy ủy quyền như vậy thường phải qua giao dịch viên, đối chiếu và phê duyệt trước khi có hiệu lực, và giao dịch bất thường có thể bị giữ lại hoặc đảo ngược. Trên Ethereum, phiếu ủy quyền có hiệu lực trong một khối 12 giây, và không có ai đứng giữa để từ chối hay hoàn tác.

Hàm quét được viết để không dừng giữa chừng

Phần lõi của hàm sweep rút gọn như sau:

for (uint256 i = 0; i < tokens.length; i++) {
    address token = tokens[i];
    if (token == address(0)) {                 // ETH
        uint256 bal = address(this).balance;
        if (bal > 1 ether) to.call{value: bal - 1 ether}("");
    } else {                                    // token ERC-20
        uint256 bal = IERC20(token).balanceOf(address(this));
        if (bal > 0 && !token.call(transfer(to, bal))) emit SweepItemFailed(token, 2);
    }
}

Có ba lựa chọn thiết kế đáng chú ý.

Thứ nhất, danh sách token do người gọi truyền vào, không khắc cứng trong mã. Lần quét đầu tiên lúc 03:24:23 truyền 65 mục: ETH và 64 token ERC-20, trong đó có USDT, RLUSD, UNI, PEPE, LINK, WBTC, SHIB.⁷ Một hợp đồng, nhiều lần dùng, mỗi lần một danh sách khác.

Thứ hai, token nào lỗi thì ghi sự kiện SweepItemFailed rồi đi tiếp, không làm hỏng cả giao dịch. Trong lần quét đầu, token Kite chuyển thất bại nhưng 63 token còn lại vẫn đi. Với kẻ tấn công, đây là bảo hiểm: một token có cơ chế chặn chuyển không thể làm hỏng cả mẻ quét trị giá hàng tỷ USD.

Thứ ba, ETH luôn được chừa lại đúng 1 ETH. Mã không nói lý do. Tôi cho rằng có hai khả năng: giữ cho ví đủ phí gas để các giao dịch thường ngày của sàn không bị lỗi và gây báo động sớm, hoặc đơn giản là chừa phí cho các thao tác tiếp theo. Đây là suy luận, không phải dữ kiện. Dữ kiện là trong buổi diễn tập, kẻ tấn công đã dùng withdrawETH để rút đúng 1 ETH chừa lại này.

Hàm thứ năm được thêm vào sau cùng

Hợp đồng quét không phải phiên bản đầu tiên. Lúc 09:28 sáng 29/10 giờ Việt Nam, gần 18 tiếng trước vụ tấn công, ví khởi phát đã triển khai một hợp đồng khác tại 0x19be…f2bf.⁸ Tôi biên dịch thử bản dựng lại sau khi bỏ hàm callExecute và nhận được bytecode trùng khớp với hợp đồng này. Nghĩa là phiên bản đầu có đủ các hàm quét, rút ETH, rút token, chỉ thiếu đúng một hàm.

Hàm được thêm vào trong phiên bản thứ hai, triển khai lúc 22:59 cùng ngày, là callExecute. Nó cho phép ví đang bị chiếm gọi hàm execute của một hợp đồng khác. Đối chiếu với lịch sử giao dịch, mục đích rất rõ: Hot Wallet 34 là một ví hợp đồng mà Binance 14 vẫn điều khiển hằng ngày bằng chính hàm execute, chẳng hạn để chuyển USDC tới các địa chỉ bên ngoài. Chiếm được Binance 14 nghĩa là chiếm luôn quyền ra lệnh cho Hot Wallet 34. Hai lệnh callExecute lúc 03:41:23 và 03:59:47 đã rút 780 triệu và 43 triệu USDC theo đúng đường này.⁹

Việc thêm hàm này sau khi đã có bản đầu cho thấy kẻ tấn công đã khảo sát cấu trúc ví của Binance khá kỹ, và điều chỉnh công cụ trong ngày chuẩn bị.

Một buổi diễn tập trên ví riêng

Lịch sử giao dịch của ví khởi phát cho thấy một quy trình kiểm thử bài bản trước giờ tấn công.

Với phiên bản đầu, họ ủy quyền hai ví thử do chính họ giữ khóa, rồi gọi sweep để kiểm tra luồng quét. Với phiên bản thứ hai, họ ủy quyền thêm một ví thử 0x43ae…04bd, quét thử bốn mục ETH, USDT, USDC, DAI, rồi gọi withdrawETH rút đúng 1 ETH sang một ví trung gian.¹⁰ Lúc 01:20 sáng 30/10, ví trung gian này chuyển lại 1,08 ETH cho ví khởi phát. Số ETH đó trở thành phí gas cho giao dịch ủy quyền hai giờ sau.

Một chi tiết nhỏ nhưng nhất quán: mỗi lần ủy quyền thử nghiệm đều kèm hai hoặc ba phiếu ký sẵn cho các nonce liên tiếp, bắt đầu từ 0. Tới lúc nhắm vào Binance 14, con số này là 50.

Năm mươi chữ ký và một cửa sổ vài phút

Phiếu ủy quyền EIP-7702 chỉ có hiệu lực khi số nonce ghi trong phiếu đúng bằng nonce hiện tại của ví ký. Với một ví cá nhân ít giao dịch, việc này dễ. Với Binance 14, một ví nóng gửi trung bình hơn hai giao dịch mỗi khối, nonce nhảy liên tục và kẻ tấn công không thể biết chắc giao dịch của mình sẽ được xếp vào lúc nào.

Lời giải là ký trước cả một dải nonce. Hình dung một xấp séc ký sẵn, mỗi tờ in một số thứ tự, và ngân hàng chỉ nhận tờ mang đúng số kế tiếp của tài khoản: không biết số kế tiếp là bao nhiêu, người ta ký cả xấp. Giao dịch lúc 03:20:59 mang 50 phiếu ủy quyền, cùng trỏ về hợp đồng quét. Tôi khôi phục khóa công khai từ từng chữ ký theo công thức của EIP-7702: cả 50 phiếu đều do khóa của Binance 14 ký, với 50 nonce liên tiếp từ 18.914.775 đến 18.914.824.¹¹

Đối chiếu với giao dịch của chính Binance 14 cho thấy phiếu nào đã có hiệu lực. Trong cùng khối 26.300.753, giao dịch thường ngày của sàn với nonce 18.914.808 đứng ngay trước giao dịch ủy quyền. Giao dịch kế tiếp của sàn ở khối sau mang nonce 18.914.810. Vậy phiếu được áp dụng là phiếu nonce 18.914.809, và nonce bị tiêu thụ đúng một bước.¹²

Chi tiết này mang ý nghĩa lớn hơn vẻ ngoài. Ở nhịp khoảng 20 giao dịch trong 9 khối 12 giây quanh thời điểm đó, dải 50 nonce chỉ tương ứng chừng 4–5 phút hoạt động của Binance 14, từ khoảng 03:18 tới 03:22. Điều đó cho thấy người chuẩn bị đã ước tính đúng nonce của ví quanh thời điểm thực thi. Nó gợi ý, nhưng chưa chứng minh, rằng chữ ký được tạo sát giờ gửi: các phiếu cũng có thể được ký trước cho một dải nonce dự đoán rồi chờ tới lúc thích hợp mới gửi. Thêm nữa, 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 một giao dịch rút tiền. Một hệ thống ký chỉ chấp nhận giao dịch rút tiền theo khuôn mẫu sẽ không ký nó.

Từ đó, theo tôi, có thể thu hẹp các giả thuyết như sau:

Tôi không gán xác suất cho từng giả thuyết. Dữ liệu trên chuỗi chỉ cho thấy người tạo các chữ ký đã có được 50 phiếu ủy quyền hợp lệ bằng khóa của Binance 14, với dải nonce khớp thời điểm thực thi quanh 03:20 sáng 30/10. Muốn đi xa hơn cần nhật ký nội bộ của sàn.

Khi kịch bản tự động gặp lệnh phong tỏa

Hợp đồng quét chạy đúng thiết kế, nhưng kịch bản điều khiển nó có một lỗ hổng: địa chỉ nhận được truyền vào mỗi lần gọi, và kẻ tấn công không đổi nó kịp thời.

Lúc 04:01:35, Tether đưa ví nhận chính 0x5227…2f8c vào danh sách phong tỏa.¹³ Hợp đồng USDT chỉ chặn ví bị phong tỏa gửi tiền đi, không chặn nhận vào, giống một tài khoản ngân hàng bị phong tỏa theo kiểu chỉ cấm rút: tiền vẫn chảy vào được, nhưng không ra được nữa. Ba phút sau, lần quét thứ hai vẫn chuyển 3,92 triệu USDT tới đúng ví ấy. Lần quét thứ ba lúc 04:44:11 chuyển tiếp 200,4 triệu USDT vừa được nạp vào Binance 14, cũng tới ví ấy.¹⁴ Khoảng 204 triệu USDT vì vậy rơi thẳng vào một ví đã bị khóa.

Lúc 05:06:23, Tether phong tỏa luôn chính Binance 14.¹³ Lần quét thứ tư lúc 05:39:35 đã đổi sang một ví nhận mới 0xa97b…8d10 và chuyển 122 loại token, nhưng mục USDT thất bại, được hợp đồng ghi lại bằng sự kiện SweepItemFailed.¹⁵ Từ 06:36 tới 06:56, ví khởi phát còn gọi sweep sáu lần nữa, chỉ với mục ETH, và không lần nào phát sinh lệnh chuyển tài sản.

Hai bài học nằm trong đoạn này. Phong tỏa của tổ chức phát hành có tác dụng thật, kể cả với một công cụ tự động. Nhưng nó có tác dụng nhờ kẻ tấn công chậm điều chỉnh, và chỉ với tài sản có chủ thể phát hành. ETH thì không.

Điều các đơn vị lưu ký nên rút ra

Hợp đồng quét không khai thác lỗ hổng nào của Ethereum hay của EIP-7702. Nó chỉ tận dụng đúng chức năng được thiết kế. Vì vậy, phòng thủ phải đặt ở phía người giữ khóa.

Thứ nhất, coi phiếu ủy quyền EIP-7702 là loại chữ ký nguy hiểm nhất. Hệ thống ký của ví nóng nên từ chối mặc định mọi thông điệp có tiền tố 0x05, trừ khi hợp đồng đích nằm trong danh sách được phê duyệt trước. Một ví nóng của sàn hầu như không có lý do gì để ủy quyền mã cho bên ngoài.

Thứ hai, giám sát giao dịch loại 4 theo thời gian thực. Bất kỳ giao dịch nào chứa phiếu ủy quyền ký bởi ví của mình đều phải kích hoạt cảnh báo mức cao nhất, ngừng nạp tiền vào ví đó và chuẩn bị sẵn quy trình ký phiếu ủy quyền về địa chỉ rỗng để thu hồi. Trong vụ này, từ lúc phiếu ủy quyền lên chuỗi tới lần quét thứ ba là 83 phút, và hệ thống của sàn vẫn nạp thêm hơn 200 triệu USDT vào ví đã bị thay bộ não.

Thứ ba, tách ví điều khiển khỏi ví giữ tiền. Hot Wallet 34 mất 823 triệu USDC không phải vì bị tấn công trực tiếp, mà vì nó tin tuyệt đối vào một ví nóng khác. Một ví hợp đồng giữ hàng trăm triệu USD nên có hạn mức theo thời gian hoặc yêu cầu nhiều chữ ký cho các lệnh lớn, thay vì chỉ cần một chủ.

Với thị trường Việt Nam, các yêu cầu này nên được đưa vào chuẩn mực vận hành của tổ chức cung cấp dịch vụ tài sản mã hóa, bên cạnh cấp độ an toàn hệ thống thông tin mà Nghị quyết số 05/2025/NQ-CP đã đặt ra và tôi đã phân tích trong bài trước.

Một tệp mã 1.674 byte không làm nên vụ tấn công. Nó chỉ là bằng chứng rõ nhất rằng, trong một thế giới mà chữ ký là quyền lực, câu hỏi quan trọng nhất của mọi hệ thống lưu ký là: ai có thể ký, và ký những gì.