Tôi vừa đọc bản nghiên cứu được trình bày tại USENIX Security '26, và nó khiến tôi phải dừng lại. 65.340 địa chỉ crypto rủi ro trên Ethereum và BNB Smart Chain, với tổn thất 126.982,94 ETH và 17.726,7 BNB – tương đương hơn 574,8 triệu USD theo giá tham chiếu tháng 5/2025 (ETH $4.408, BNB $847). Nhưng điều thú vị là chỉ có 3.472,23 ETH và 465,24 BNB (khoảng 15,7 triệu USD, tức 2,7%) đến từ hai vector tấn công mới được mô tả. Phần còn lại là hậu quả của những lỗi cũ: private key bị lộ, gửi nhầm địa chỉ không có code, và những kịch bản mà chúng ta tưởng đã hiểu rõ.
Bối cảnh thị trường hiện tại đang giảm, và tôi nhận thấy một xu hướng đáng lo ngại: khi giá giảm, người dùng thường hoảng loạn chuyển tiền, tạo cơ hội cho kẻ tấn công. Nhưng nghiên cứu này không chỉ nói về những vụ hack mới; nó phơi bày một lớp rủi ro ngầm đã tồn tại hàng năm. Hãy cùng tôi mổ xẻ hai vector chính, và tại sao góc nhìn phản trực giác lại quan trọng hơn con số.
Vector 1: Contract-account misuse – Khi testnet trở thành bẫy mainnet
Cơ chế đơn giản đến khó tin: một người dùng gửi giao dịch (thường kèm ETH hoặc BNB) đến một địa chỉ hợp đồng trên mainnet, nhưng địa chỉ đó không có code. Giao dịch vẫn thành công như một chuyển khoản thông thường, và số tiền bị mắc kẹt. Kẻ tấn công lợi dụng tính năng deterministic contract addressing (CREATE2) để triển khai hợp đồng độc hại tại cùng địa chỉ đó trên mainnet, sau đó rút tiền. Nghiên cứu phát hiện 469 hợp đồng độc hại, gây thiệt hại 3.446,37 ETH và 431,79 BNB.
Tôi từng theo dõi các vụ tương tự trong đợt sụp đổ FTX, và tôi thấy mô hình này lặp lại: các nhà phát triển thường triển khai hợp đồng thử nghiệm trên testnet, nhưng quên xóa địa chỉ khỏi mã nguồn frontend. Người dùng sao chép địa chỉ từ GitHub, gửi tiền mà không kiểm tra chain. Dữ liệu on-chain không nói dối: các bot quét GitHub đã tìm thấy 16,3 triệu private key duy nhất từ 63.004 repo. Trong số đó, nhiều key thuộc về testnet, nhưng khi dùng deterministic addressing, chúng trở thành công cụ để đánh cắp.
Vector 2: EOA misuse + EIP-7702 – Khi private key lộ trở thành delegation
Vector thứ hai tinh vi hơn. Private key bị lộ (từ GitHub, pastebin, hoặc leak cũ) cho phép kẻ tấn công kiểm soát tài khoản. Nhưng với EIP-7702, chúng có thể delegate tài khoản đó đến một hợp đồng độc hại, tự động chuyển tiếp mọi khoản tiền gửi đến địa chỉ của kẻ tấn công trong cùng một giao dịch. Nghiên cứu xác định hơn 17.200 địa chỉ bị delegate, với tổn thất 25,86 ETH và 33,45 BNB.
Xung lực thanh khoản đang chuyển hướng từ các ví ‘chết’ sang kẻ tấn công, và EIP-7702 làm tăng tốc quá trình này. Khi mọi người đều lạc quan về tính linh hoạt của tài khoản thông minh, tôi lại thấy một bề mặt tấn công mới. Bộ công cụ sovereign individual bao gồm việc tự quản lý key, nhưng nếu key bị lộ, bạn không còn là chủ nhân nữa.
Phân tích kỹ thuật sâu hơn
Nhóm nghiên cứu đã xây dựng bộ dữ liệu bằng cách khai thác 63.004 repo GitHub từ tháng 1/2015 đến tháng 5/2025, kết hợp với dữ liệu Stack Exchange. Họ trích xuất hơn 16,3 triệu private key, suy ra địa chỉ, và áp dụng quy tắc giao dịch kết hợp với thực thi ký hiệu nhẹ. Kết quả đạt độ chính xác 99,11% – một con số ấn tượng, nhưng cần hiểu rõ: nó đo lường độ chính xác của phát hiện, không phải tổn thất trực tiếp từ hai vector.
Trong quá trình audit của tôi, tôi thường thấy các dự án hardcode private key trong file cấu hình, và nghiên cứu này xác nhận điều đó. 63.000 repo chứa key – đó là một thảm họa bảo mật. Các red flag tôi tìm thấy trong tài liệu của họ bao gồm việc không có cơ chế cảnh báo khi gửi đến địa chỉ không có code. Wallet providers vẫn chưa tích hợp tính năng kiểm tra này một cách phổ biến.
Góc nhìn phản trực giác
Nghiên cứu tập trung vào lỗi người dùng, nhưng tôi cho rằng giao thức DeFi cũng có trách nhiệm. Hầu hết các giao thức không kiểm tra địa chỉ đích có tồn tại code hay không trước khi cho phép giao dịch. Một số sàn DEX cho phép swap đến bất kỳ địa chỉ nào, kể cả địa chỉ ‘chết’. Điều này tạo ra một bề mặt tấn công gián tiếp. Hơn nữa, con số $574,8 triệu có thể bị phóng đại vì giá tham chiếu không phải thời điểm mất, nhưng vấn đề thực sự là hàng ngàn địa chỉ đang chờ bị đánh cắp. Tôi dự đoán trong 12 tháng tới, các bot tự động sẽ quét GitHub và mạng lưới testnet nhanh hơn, gây ra làn sóng tấn công mới.
Takeaway
Người dùng nên kiểm tra cả địa chỉ và chain thông qua nguồn chính thức. Nhà phát triển cần loại bỏ hardcoded key và dùng CI/CD để quét. Wallet providers có thể cảnh báo trước khi giao dịch đến địa chỉ không có code hoặc key đã lộ. Câu hỏi đặt ra: Liệu các sàn giao dịch có đủ khả năng ngăn chặn dòng tiền từ 65.340 địa chỉ rủi ro này? Hay chúng ta sẽ chứng kiến một vụ thanh lý thầm lặng kéo dài?