Mỗi tháng, một nhóm người lạ mặt gọi điện cho nhân viên Binance. Họ giả làm IT, giả làm sếp, giả làm đối tác. Nếu ai đó mắc bẫy – ví dụ, nhấp vào link giả mạo hoặc cung cấp mật khẩu – thì không có hậu quả kỷ luật. Chỉ có một cuộc họp rút kinh nghiệm. Nghe có vẻ nhẹ nhàng, nhưng đây là một trong những biện pháp phòng thủ đắt đỏ nhất mà tôi từng thấy ở một sàn giao dịch.
Tôi đã viết code cho ba layer2 khác nhau. Tôi biết cảm giác khi phát hiện một lỗi trong fraud proof sau ba tháng debug. Nhưng điều làm tôi mất ngủ không phải là lỗi trong smart contract – mà là một tin nhắn Slack giả mạo từ ‘đồng nghiệp’ yêu cầu private key. Bởi vì code có thể được audit, còn con người thì không.
Hãy bắt đầu với context. Red teaming là một phương pháp kiểm tra an ninh: một đội ‘đỏ’ đóng vai hacker tấn công hệ thống và nhân viên của tổ chức. Mục tiêu là tìm ra lỗ hổng trước khi kẻ xấu thực sự khai thác. Binance đã áp dụng phương pháp này hàng tháng cho tất cả nhân viên. Theo bài báo gốc, xã hội kỹ thuật (social engineering) đã trở thành nguồn rò rỉ chính trong ngành. Điều này không mới. Năm 2022, một vụ tấn công vào sàn giao dịch lớn đã làm mất hàng trăm triệu USD chỉ vì một nhân viên kỹ thuật bị lừa tải phần mềm độc hại.
Nhưng có một chi tiết kỹ thuật thú vị ở đây: tần suất. Mỗi tháng một lần. So với tiêu chuẩn ngành – thường là mỗi quý hoặc mỗi năm – Binance đang đầu tư gấp ba lần vào việc huấn luyện con người. Điều này cho thấy họ coi yếu tố con người là vector tấn công nguy hiểm nhất. Và tôi đồng ý. Trong 27 năm quan sát ngành, tôi chưa thấy một hệ thống nào an toàn tuyệt đối khi người vận hành có thể bị thao túng.
Phân tích core: Hãy nhìn vào mã nguồn của một cuộc tấn công social engineering điển hình. Nó không cần smart contract, không cần exploit zero-day. Chỉ cần một email HTML tinh vi, một trang đăng nhập giả hoàn hảo, và một chút kiến thức tâm lý. Tôi từng viết script Python để scrape dữ liệu on-chain từ Uniswap V2; tôi biết dữ liệu phi tập trung có thể bị nhiễm độc bởi một giao dịch độc hại. Nhưng so với việc lừa một người gõ private key vào Google Docs, thì đó là chuyện nhỏ.
Tôi đã thử nghiệm với một mô hình ML phân tích transaction history trên Near Protocol; tôi phát hiện ra các pattern spam attack mà rule-based không bắt được. Nhưng khi tôi hỏi các operator của layer2 rằng họ có chương trình chống social engineering không, câu trả lời thường là ‘chúng tôi có multisig’. Multisig không giúp ích gì nếu cả ba người ký đều bị lừa cung cấp chữ ký.
Điểm mấu chốt: Red teaming không chỉ là kiểm tra – nó là văn hóa. Nếu một tổ chức không tạo ra môi trường an toàn để nhân viên mắc lỗi, họ sẽ giấu lỗi. Binance chọn cách không phạt, chỉ rút kinh nghiệm. Đó là một quyết định kỹ thuật tinh tế: giảm thiểu rủi ro báo cáo sai lệch. Tuy nhiên, tôi thấy một vấn đề: họ không công bố kết quả kiểm tra. Không có số liệu, không có tỷ lệ thành công. Điều này tạo ra hiệu ứng ‘hộp đen’ – chúng ta chỉ biết họ làm, không biết hiệu quả ra sao.
Góc nhìn phản trực giác (Contrarian): Đa số mọi người nghĩ rằng red teaming là dấu hiệu của một tổ chức an toàn. Tôi nói rằng nó có thể là dấu hiệu của sự tự mãn. Khi bạn đã quen với các bài kiểm tra hàng tháng, bạn sẽ tạo ra một ‘miễn dịch giả’: nhân viên chỉ cảnh giác với các cuộc tấn công giả, nhưng lại mất cảnh giác với các cuộc tấn công thật ngoài kịch bản. Các hacker thực thụ không bao giờ theo kịch bản. Họ thích nghi nhanh hơn. Tôi đã chứng kiến một dự án layer2 có audit code hoàn hảo nhưng bị tấn công qua một cuộc gọi điện thoại giả mạo hỗ trợ kỹ thuật. Kẻ tấn công chỉ cần hỏi ‘Anh có đang gặp vấn đề với testnet không?’ – và operator đã cung cấp toàn bộ cấu hình node.
Bảo mật là một vòng lặp, không phải trạng thái. Red teaming chỉ là một bước trong OODA loop (Observe, Orient, Decide, Act). Nếu Binance không thường xuyên cập nhật kịch bản tấn công dựa trên dữ liệu real-world, thì các bài kiểm tra đó trở nên lãng phí. Tôi đã thấy điều này trong quá trình audit mã nguồn EOS: họ có bộ kiểm tra rất tốt, nhưng khi mainnet ra mắt, lỗ hổng DPoS vẫn tồn tại vì các test case không bắt kịp hành vi thực tế của block producer.
Takeaway: Trong 18 tháng tới, tôi dự đoán social engineering sẽ vượt qua lỗi smart contract để trở thành nguyên nhân số một gây mất tiền trong crypto. Các layer2 đang chạy đua về TPS, về zk-proof, nhưng quên rằng sequencer của họ là con người. Một cuộc gọi lừa đảo có thể vô hiệu hóa toàn bộ hệ thống. Nếu bạn là builder, hãy đầu tư vào văn hóa bảo mật, không chỉ vào audit code. Nếu bạn là user, hãy nhớ: không có layer2 nào bảo vệ bạn khỏi một cú click chuột sai.
Câu hỏi kết thúc: Khi tin tặc gọi cho operator layer2 của bạn, anh ta sẽ trả lời thế nào? Và bạn đã chuẩn bị cho câu trả lời đó chưa?
