DeFi thường xuyên bị trộm cắp, trong thời đại AI làm thế nào để phòng ngừa các cuộc tấn công của hacker?

Viết bài: systs

OpenBuild giới thiệu:

Tháng 4 năm 2026, DeFi bước vào thời điểm đen tối nhất, số tiền bị đánh cắp trong tháng vượt quá 625 triệu USD, lập kỷ lục lịch sử, chỉ riêng Drift và KelpDAO đã tiêu thụ gần 580 triệu USD trong hai vụ tấn công. Sự bùng nổ của AI đã hoàn toàn đảo lộn cục diện phòng thủ và tấn công, những lỗ hổng hợp đồng chỉ mất vài tuần để kiểm tra thủ công giờ đây có thể được xử lý trong vài giờ bằng mô hình lớn, chi phí tấn công giảm mạnh, phạm vi tấn công mở rộng, ngày càng nhiều giao thức trở thành mục tiêu.

Những kẻ tấn công chuyên nghiệp có nguồn lực dồi dào, thành thạo trong chiến lược dài hạn, đang nhắm vào từng khe hở của các giao thức, trong khi các nhóm bình thường phân tán nguồn lực, phòng thủ bị động và dễ tổn thương, chỉ có thể sống sót bằng cách duy trì sự cực đoan, xây dựng phòng thủ toàn diện từ trước, kiểm soát thiệt hại chặt chẽ và chuẩn bị kế hoạch dự phòng. Dưới đây là nội dung gốc do OpenBuild biên tập và tổng hợp.

Sau khi phát triển dự án @openforage, nghiên cứu nhiều vụ tấn công lịch sử của các giao thức DeFi, tôi bắt đầu cảnh giác với các đối thủ cấp quốc gia. Những đối thủ này có kỹ năng thành thạo, nguồn lực dồi dào, thành thạo trong chiến lược dài hạn; như những phản diện hàng đầu, họ sẽ kiểm tra kỹ từng khe hở của giao thức và hạ tầng cơ sở của bạn để tìm lỗ hổng có thể khai thác. Trong khi đó, các nhóm giao thức bình thường thường phân tán nguồn lực, vừa vận hành kinh doanh vừa đảm bảo an toàn, không thể toàn tâm toàn ý phòng thủ. Tôi không tự nhận là chuyên gia an ninh, nhưng tôi từng chỉ huy trong môi trường rủi ro cao (có kinh nghiệm quân đội, từng quản lý số tiền lớn trong các tổ chức tài chính lớn), có kinh nghiệm thực chiến về kế hoạch rủi ro và ứng phó khẩn cấp. Tôi luôn tin rằng: chỉ những người cực đoan mới có thể tồn tại. Không có nhóm nào bắt đầu với tâm thế “an toàn qua loa”, nhưng các cuộc tấn công hacker vẫn liên tục xảy ra. Chúng ta phải làm tốt hơn nữa.

/ 01 Thời đại AI: Mọi thứ đã khác

Các cuộc tấn công hacker vốn không hiếm, nhưng gần đây tần suất tăng rõ rệt. Quý 1 năm 2026 đã lập kỷ lục về số vụ tấn công hacker trong lịch sử DeFi, và quý 2 mới bắt đầu, đã có khả năng phá vỡ kỷ lục của quý trước.

Quan điểm cốt lõi của tôi là: AI đã giảm mạnh chi phí quét và khai thác lỗ hổng, đồng thời mở rộng đáng kể phạm vi tấn công. Việc kiểm tra cấu hình của hàng trăm giao thức thủ công mất vài tuần; trong khi mô hình lớn mới nhất chỉ cần vài giờ để hoàn thành. Điều này hoàn toàn thay đổi logic cơ bản của phòng thủ an ninh và ứng phó khẩn cấp của các giao thức. Những giao thức sinh ra trước thời AI nổi lên, vẫn dựa trên các phương pháp an ninh truyền thống, đang đối mặt với rủi ro bị tấn công chính xác cao.

/ 02 Từ góc độ phạm vi tấn công và phòng thủ phân lớp

Trên thực tế, có ba loại điểm tấn công chính trong các cuộc tấn công DeFi:

Nhóm vận hành giao thức

Hợp đồng thông minh và hạ tầng cơ sở

Giới hạn niềm tin của người dùng (tên miền, mạng xã hội, v.v.)

Sau khi xác định điểm tấn công, xây dựng hệ thống phòng thủ phân lớp gồm năm tầng:

Phòng ngừa trước: thiết lập quy trình tiêu chuẩn, thực thi nghiêm ngặt để giảm thiểu khả năng bị tấn công nhất có thể.

Giảm thiểu thiệt hại: khi phòng ngừa thất bại, kiểm soát quy mô thiệt hại ngay lập tức.

Dừng hoạt động khẩn cấp: dưới áp lực cao, không ai có thể đưa ra quyết định tối ưu. Khi xác định bị tấn công, kích hoạt ngay công tắc dừng khẩn cấp, phong tỏa tài sản để ngăn thiệt hại mở rộng, đồng thời dành thời gian cho nhóm phân tích bình tĩnh.

Thu hồi quyền kiểm soát: nếu module độc hại hoặc thành phần bị xâm nhập đã mất kiểm soát, loại bỏ hoặc thay thế trực tiếp.

Phục hồi sau sự cố: thu hồi tài sản bị đánh cắp. Liên kết trước với các đối tác, có thể phong tỏa quỹ, hoàn nguyên giao dịch, hỗ trợ điều tra nguồn gốc.

/ 03 Nguyên tắc cốt lõi

Các nguyên tắc dưới đây hướng dẫn chúng ta triển khai toàn bộ hệ thống phòng thủ phân lớp.

Tăng cường phòng thủ bằng AI tiên tiến

Tận dụng tối đa các mô hình lớn tiên tiến để quét lỗ hổng trong mã nguồn và cấu hình, tiến hành kiểm tra xâm nhập đỏ xanh trong phạm vi tấn công rộng lớn: chủ động khai thác lỗ hổng frontend, xác nhận khả năng xâm nhập backend qua đó. Kẻ tấn công chắc chắn sẽ làm như vậy; phòng thủ bằng cách quét các lỗ hổng có thể phát hiện cũng sẽ giúp phát hiện các cuộc tấn công của hacker. Có thể sử dụng các công cụ như pashov, nemesis, cùng các nền tảng an ninh AI như Cantina (Apex), Zellic (V12), để nhanh chóng sơ bộ mã nguồn trước khi tiến hành kiểm toán chính thức.

Thời gian và quy trình chính là hàng rào phòng thủ

Tất cả các thao tác có nguy cơ rủi ro đều cần thiết kế theo quy trình nhiều bước + cơ chế khóa thời gian. Khi phát hiện bất thường, cần có đủ thời gian để can thiệp thủ công và phong tỏa tài sản. Trước đây, ngành thường phản đối khóa thời gian, phân quyền nhiều bước vì sợ làm chậm tiến độ và ảnh hưởng hiệu quả vận hành nhóm. Nhưng giờ đây, tình hình đã khác: AI có thể tự động vượt qua các quy trình thủ công này, việc giao thức vẫn giữ thao tác đơn giản là vô nghĩa.

Thiết kế bất biến

Hợp đồng thông minh có thể định nghĩa các bất biến cốt lõi không thể vi phạm để phòng thủ: nếu quy tắc này bị phá vỡ, toàn bộ logic của hợp đồng sẽ vô hiệu. @openforage tập trung vào thiết kế bất biến dựa trên khả năng thanh toán: tổng tài sản trong kho + tài sản đã triển khai ≥ các khoản nợ chưa thanh toán. Các hợp đồng chỉ cần đặt một số bất biến quan trọng; không nên hardcode nhiều kiểm tra cho từng hàm, vì sẽ làm mã phức tạp và khó bảo trì.

Cân bằng quyền lực

Nhiều cuộc tấn công bắt nguồn từ lộ khóa riêng của ví hoặc bị tấn công đa chữ ký. Cấu hình quyền hợp lý cần đảm bảo: ngay cả khi đa chữ ký bị mất kiểm soát, vẫn có thể nhanh chóng cắt lỗ, đưa hợp đồng về trạng thái ổn định do quản trị quyết định. Hai nguyên tắc chính cần cân nhắc:

Quyền quản trị: kiểm soát các quyết định cốt lõi của hợp đồng

Quyền ứng cứu khẩn cấp: chịu trách nhiệm khôi phục trật tự ổn định có thể quản trị, nhưng không có quyền thay thế hoặc lật đổ hệ thống quản trị ban đầu

Dự phòng sự cố

Phải xây dựng nhận thức nền tảng rằng: bất kể nhóm có chuyên nghiệp đến đâu, cuối cùng cũng sẽ gặp phải tấn công. Các hợp đồng thông minh hoặc thành phần phụ thuộc có thể gặp lỗi, nhóm có thể bị lừa đảo xã hội, việc nâng cấp phiên bản cũng có thể giới thiệu lỗ hổng mới. Với tâm thế này, các biện pháp kiểm soát dòng chảy, cắt cơn và dừng hoạt động là bắt buộc: giới hạn thiệt hại trong 5-10%, phong tỏa tài sản rồi từ từ xây dựng kế hoạch ứng phó. Trong tình huống khẩn cấp, tuyệt đối không đưa ra quyết định vội vàng.

Lập kế hoạch ứng phó sớm

Phản ứng tốt nhất với tấn công là trước khi xảy ra sự cố. Cần chuẩn bị quy trình ứng phó thành quy định, viết thành tài liệu, luyện tập nhiều lần để tránh hoảng loạn khi có sự cố. Thời đại AI đòi hỏi: phải có công cụ và thuật toán phù hợp, tập trung toàn bộ thông tin trong thời gian ngắn, có thể tạo ra tóm tắt ngắn gọn và chi tiết đầy đủ, gửi đồng bộ đến các quyết định trung tâm.

Sống còn là mục tiêu tối thượng

Không cần phải hoàn hảo tuyệt đối, nhưng phải đảm bảo tồn tại. Không có hệ thống nào từ khi ra mắt đã vững chắc như đá; chỉ có thể trưởng thành qua việc liên tục xem lại, rút ra bài học, xây dựng kiến trúc chống đổ vỡ. Chưa từng bị hacker tấn công không có nghĩa là an toàn tuyệt đối; thời điểm yên bình nhất chính là lúc rủi ro cao nhất.

/ 04 Hệ thống phòng ngừa trước

Thiết kế hợp đồng thông minh

Xác định các bất biến cốt lõi rồi đưa vào logic kiểm tra thời gian chạy, cẩn thận chọn lọc các quy tắc cần kiểm tra bắt buộc. Khuyến nghị theo mô hình thiết kế FREI-PI (Yêu cầu hàm - Ảnh hưởng thực thi - Giao tiếp bên ngoài - Bất biến của hợp đồng): tất cả các hàm liên quan đến biến động tài sản, sau khi thực thi, kiểm tra lại các bất biến cốt lõi cần bảo vệ. Nhiều cuộc tấn công như arbitrage flash loan, thanh lý oracle độc hại, thanh toán chéo hàm, đều có thể bị chặn bởi kiểm tra bất biến cuối hàm.

Hoàn thiện hệ thống kiểm thử

Kiểm thử mờ trạng thái: tạo các chuỗi gọi ngẫu nhiên cho toàn bộ API của hợp đồng, kiểm tra bất biến ở mỗi bước. Hầu hết các cuộc tấn công trên chain đều là tấn công phối hợp nhiều giao dịch, kiểm thử mờ trạng thái là cách duy nhất để phát hiện lỗ hổng trước hacker. Viết các kiểm thử bất biến, đảm bảo quy tắc luôn đúng trong mọi chuỗi gọi ngẫu nhiên do kiểm thử tạo ra; kết hợp xác thực hình thức để chứng minh quy tắc luôn hiệu lực trong mọi trạng thái có thể đạt tới. Các bất biến cốt lõi của hợp đồng phải được xác thực hình thức.

Oracle và phụ thuộc bên ngoài

Độ phức tạp chính là kẻ thù lớn nhất của an toàn. Mỗi lớp phụ thuộc bên ngoài làm tăng phạm vi tấn công. Nếu bạn phát triển các thành phần nền tảng, nên để người dùng tự chọn độ tin cậy; nếu không thể loại bỏ phụ thuộc, cần thực hiện đa nguồn phân tán, tránh điểm yếu đơn lẻ kéo sập toàn bộ hợp đồng. Phạm vi kiểm toán phải bao gồm các lỗi của oracle và phụ thuộc bên ngoài, đặt giới hạn hạn mức, để dù có sự cố cũng kiểm soát thiệt hại trong phạm vi cho phép. Vụ tấn công của KelpDAO gần đây là ví dụ điển hình: dự án dùng cấu hình LayerZero mặc định requiredDVNCount=1, không nằm trong phạm vi kiểm toán; cuối cùng bị tấn công chính là hạ tầng ngoài kiểm toán.

Xem xét toàn diện các điểm tấn công

Các vector tấn công đã được liệt kê đầy đủ trong danh sách các lỗ hổng DeFi đã biết. So sánh từng mục, xác định phù hợp với giao thức của mình, thực hiện các biện pháp kiểm soát tương ứng. Xây dựng khả năng red-blue team nội bộ, bắt buộc AI tự tìm ra lỗ hổng của giao thức; đây đã là tiêu chuẩn ngành hiện nay.

Quyền cứu hộ khẩn cấp tích hợp sẵn

Trong mô hình quản trị bỏ phiếu, quyền lực ban đầu tập trung cao độ vào nhóm đa chữ ký, sau đó phân tán dần. Dù token phân phối rộng, quyền ủy thác thường thu hẹp về một số ví chính, thậm chí chỉ còn một địa chỉ quan trọng. Nếu ví này bị tấn công, hợp đồng sẽ sụp đổ ngay lập tức. Đề xuất triển khai ví bảo vệ, giới hạn quyền hạn chặt chẽ: chỉ có thể tạm dừng hợp đồng; trong trường hợp cực đoan, cần đạt 4/7 trở lên để chuyển quyền ủy thác bị xâm phạm sang ví dự phòng đã chuẩn bị sẵn. Ví bảo vệ không có quyền khởi tạo hoặc thông qua đề xuất quản trị.

Như vậy, hợp đồng có một lớp cứu hộ khẩn cấp độc lập: vừa có thể khôi phục trạng thái ổn định có thể quản trị, vừa không thể lật đổ hệ thống quản trị gốc. Xác suất tất cả hơn 4/7 ví bảo vệ cùng bị xâm phạm là rất thấp do phân tán địa chỉ nắm giữ token; khi hệ thống quản trị trưởng thành, quyền hạn phân tán đầy đủ, có thể dần loại bỏ lớp cứu hộ này.

Cấu trúc ví và chìa khóa

Ví đa chữ ký là tiêu chuẩn, tối thiểu dùng cấu trúc 4/7, không ai có thể kiểm soát toàn bộ 7 chìa khóa riêng. Thường xuyên thay đổi địa chỉ ký một cách âm thầm. Chìa khóa ký không được dùng chung cho các thiết bị hàng ngày: nếu thiết bị ký dùng để duyệt web, gửi email, đăng nhập phần mềm văn phòng, coi như đã bị xâm nhập. Sử dụng nhiều bộ ví đa chữ ký, phân công nhiệm vụ rõ ràng. Ít nhất một bộ ví sẽ bị tấn công hoàn toàn, dựa trên giả thiết này để xây dựng kế hoạch dự phòng. Dù bị đe dọa, cưỡng chế, hoặc đe dọa thân thể, cá nhân cũng không có quyền tấn công một mình để chiếm đoạt hợp đồng.

Kế hoạch thưởng bug bounty

Tôi đồng tình với quan điểm của Nascent về bug bounty. Các giao thức có tài chính mạnh nên đặt phần thưởng bug bounty tỷ lệ cao so với tổng giá trị bị khóa (TVL); dù quy mô nhỏ, phần thưởng cũng nên hấp dẫn (ít nhất bảy số). Đối mặt với các hacker cấp quốc gia, đàm phán thưởng có thể không hiệu quả; nhưng có thể triển khai chương trình bảo vệ an toàn cho white hat: ủy quyền cho white hat bảo vệ quỹ bị đánh cắp, lấy phần trăm làm phần thưởng, về bản chất là người gửi tiền phải gánh chịu chi phí thưởng.

Lựa chọn tổ chức kiểm toán chất lượng cao

Trước đây tôi nghĩ rằng, khi khả năng của mô hình lớn tăng lên, giá trị biên của kiểm toán truyền thống sẽ giảm, nhưng giờ tôi đã thay đổi quan điểm:

Các tổ chức kiểm toán hàng đầu luôn đi đầu. Nếu hợp đồng sử dụng thiết kế sáng tạo, mã nguồn và lỗ hổng tiềm năng không nằm trong dữ liệu huấn luyện của mô hình, việc tăng cường sức mạnh tính toán chưa chắc đã giúp phát hiện các logic lỗ hổng mới. Không ai muốn trở thành nạn nhân đầu tiên của các phương pháp tấn công mới.

Điều dễ bị bỏ qua là: các tổ chức kiểm toán sẽ dựa vào uy tín ngành để bảo chứng. Sau khi phát hành báo cáo kiểm toán, nếu hợp đồng bị tấn công, tổ chức có động cơ mạnh mẽ để hỗ trợ phân tích và hạn chế thiệt hại. Hợp tác lâu dài với các nhóm an ninh chuyên nghiệp chính là một tài sản quý giá.

Triển khai vận hành an toàn

Đưa an toàn vận hành vào tiêu chí đánh giá cốt lõi. Thường xuyên tổ chức diễn tập phishing; thuê đội đỏ bên ngoài đáng tin cậy để kiểm tra tấn công xã hội vào nhóm. Có sẵn ví cứng và thiết bị dự phòng, có thể thay thế toàn bộ cấu hình đa chữ ký, tránh tình trạng mua sắm hoặc sửa chữa gấp khi có sự cố.

/ 05 Giảm thiểu thiệt hại

Giới hạn rút tiền là giới hạn thiệt hại tối đa

Tất cả các kênh rút tiền đều phải đặt giới hạn hạn mức; thiệt hại tối đa có thể xảy ra qua kênh đó phải được khóa chặt. Nói cách khác: hàm tạo token không có giới hạn trên mỗi block tương đương với việc mở rộng vô hạn lỗ hổng tạo token; hàm rút tiền không có giới hạn tuần cũng tương đương cho phép lỗ hổng chỉnh sửa số dư tài sản. Cần cẩn thận thiết lập giới hạn cứng cho từng kênh rút tiền, cân bằng giữa thiệt hại tối đa chấp nhận được và trải nghiệm người dùng tối đa. Khi phòng tuyến bị phá vỡ, giới hạn này sẽ giúp tránh hợp đồng về 0 hoàn toàn.

Danh sách trắng và danh sách đen

Hầu hết các hợp đồng đều có danh sách ẩn các API có thể gọi, tài sản có thể giao dịch, địa chỉ có thể ủy quyền, hoặc các giới hạn hành vi cấm người dùng. Ngay cả khi quy tắc là ẩn, cũng cần quy định rõ ràng bằng văn bản. Sau khi xác định danh sách trắng đen, có thể thiết lập cơ chế thay đổi quyền hai bước, tạo thêm độ ma sát cho tấn công. Kẻ tấn công phải thay đổi danh sách trắng / loại bỏ hạn chế danh sách đen, rồi mới thực hiện thao tác độc hại. Với cơ chế kép này, các vector tấn công mới của hacker phải vượt qua hai lớp: đầu tiên qua kiểm duyệt (tích hợp / đưa vào vận hành), rồi mới vượt qua các lệnh cấm an toàn (xác minh rủi ro).

/ 06 Thu hồi quyền kiểm soát

Giám sát tự động bằng thuật toán

Có công tắc dừng khẩn cấp nhưng không có người vận hành, coi như vô dụng. Xây dựng hệ thống giám sát off-chain, theo dõi liên tục các bất biến cốt lõi 24/7, tự động nâng cấp cảnh báo khi phát hiện bất thường. Chuỗi cảnh báo cuối cùng gửi đến nhóm đa chữ ký bảo vệ, kèm theo toàn bộ ngữ cảnh, hỗ trợ quyết định trong vòng vài phút.

Dừng hoạt động rồi phân tích

Khi gặp tấn công, ưu tiên dừng hoạt động để cầm máu, đừng đưa ra quyết định vội vàng trong thời gian đếm ngược. Đối với hợp đồng, chính là kích hoạt công tắc dừng khẩn cấp (hiển thị trên frontend): chỉ cần một giao dịch để tạm dừng tất cả các luồng chuyển tài sản. Chuẩn bị sẵn script “tạm dừng tất cả trong một cú nhấn”, tự động duyệt tất cả các module có thể tạm dừng, thực thi nguyên tử. Quyền quản trị không thể bị tạm dừng; nếu quyền này bị tạm dừng, khi nhóm bảo vệ bị xâm nhập, quá trình khôi phục sẽ bị khóa vĩnh viễn.

Khởi động phòng chiến dịch khẩn cấp

Sau khi phong tỏa tài sản, ngăn chặn thiệt hại, triệu tập các nhân vật chủ chốt đã được chuẩn bị sẵn, xây dựng kênh liên lạc riêng. Giới hạn quyền truy cập thông tin, tránh để lộ cho hacker, dư luận hoặc các kẻ trục lợi. Phân chia rõ vai trò và luyện tập:

Người ra quyết định: tổng thể, quyết định chiến lược

Nhân viên vận hành: thực thi các script phòng thủ, kích hoạt dừng khẩn cấp theo chỉ đạo

Người phân tích lỗ hổng: phân tích chuỗi tấn công, xác định nguyên nhân

Liên lạc viên: liên hệ các đối tác quan trọng

Nhân viên ghi chép sự kiện: ghi lại toàn bộ diễn biến, quyết định và thời gian

Nhân sự rõ ràng, luyện tập trước, khi sự cố xảy ra theo đúng quy trình, không hoảng loạn.

Dự đoán rủi ro chuỗi liên hoàn

Mặc định hacker có trình độ cao nhất: lỗ hổng đầu tiên có thể chỉ là thủ đoạn đánh lạc hướng hoặc là bước chuẩn bị cho các cuộc tấn công liên hoàn sau đó. Vụ xâm nhập này cũng có thể là mồi nhử, dẫn dụ chúng ta thực hiện các thao tác sai, kích hoạt lỗ hổng sâu hơn. Các thao tác dừng hoạt động phải được đánh giá kỹ lưỡng, hoàn chỉnh, không để lại lỗ hổng khai thác. Giao thức cần toàn bộ bị đóng băng, tuyệt đối không chỉ dừng một module, vì sẽ lộ ra các điểm yếu khác. Sau khi xác định nguyên nhân và vector tấn công, đồng thời kiểm tra các điểm tấn công liên quan và rủi ro chuỗi, sửa chữa toàn diện một lần.

Kích hoạt cơ chế luân chuyển kế nhiệm đã được thiết lập sẵn

Chỉ an toàn khi các địa chỉ kế nhiệm đã được đăng ký trước. Tôi ủng hộ cơ chế đăng ký danh sách các địa chỉ kế nhiệm đã được thiết lập sẵn: hacker rất khó để tráo đổi ví bảo vệ / ví quản trị bằng ví độc hại. Nguyên tắc này tương tự như kiểm soát rủi ro danh sách trắng đen. Tất cả các vai trò quan trọng đều đăng ký trước địa chỉ kế nhiệm. Quyền khẩn cấp chỉ cho phép thực hiện một thao tác duy nhất: thay thế vai trò X bằng người kế nhiệm đã đăng ký trước. Trong thời bình, có thể cẩn thận chọn lọc, thẩm định kỹ các người kế nhiệm, không cần quyết định vội vàng khi có sự cố.

Thử nghiệm cẩn thận trước khi nâng cấp phiên bản

Sau khi xác định nguyên nhân và phạm vi ảnh hưởng, cần phát hành bản vá nâng cấp hợp đồng. Đây là bước triển khai mã rủi ro cao nhất: trong áp lực, viết vội, đối thủ đã nắm rõ logic hợp đồng và các lỗ hổng. Tuyệt đối không bỏ qua kiểm thử trước khi ra mắt chính thức. Nếu không có thời gian kiểm toán chính thức, có thể dùng mạng lưới white hat, hoặc mở cuộc thi bug bounty 48 giờ trước khi ra mắt, để đưa ra góc nhìn phòng thủ và tấn công của bên thứ ba trước khi chính thức triển khai.

/ 07 Phục hồi sau sự cố

Hành động nhanh chóng

Quỹ bị đánh cắp có thời gian bán chuộc, sau khi tấn công, hacker sẽ nhanh chóng phân tách và chuyển cross-chain để rửa tiền. Liên hệ sớm với Chainalysis hoặc các dịch vụ phân tích on-chain khác, theo dõi các địa chỉ hacker đa chuỗi, đồng bộ cảnh báo rủi ro của sàn giao dịch, theo dõi hành trình chuyển tiền cross-chain. Chuẩn bị danh sách: bộ phận tuân thủ của sàn tập trung, nhà vận hành cầu nối cross-chain, quản trị viên các tổ chức lưu ký, và tất cả các đối tác có khả năng phong tỏa thông điệp cross-chain, chặn tài sản đang trong quá trình chuyển.

Thương lượng đàm phán

Dù không muốn, vẫn khuyên nên chủ động liên hệ với hacker. Mọi thứ đều có thể thương lượng. Công bố sớm phần thưởng white hat, cam kết hoàn trả đầy đủ trong thời hạn, từ bỏ mọi trách nhiệm pháp lý. Nếu đối thủ là lực lượng cấp quốc gia, khả năng đàm phán thành công rất thấp; nhưng nhiều hacker chỉ tình cờ phát hiện lỗ hổng, muốn kiếm lợi thầm lặng, vẫn còn khả năng thương lượng. Luôn có sự tham gia của bộ phận pháp lý trong suốt quá trình.

/ 08

Các cuộc tấn công hacker sẽ không biến mất, cùng với sự tiến bộ của AI, tần suất tấn công sẽ ngày càng tăng. Phòng thủ chỉ dựa vào chính mình là không đủ, phải sử dụng các công cụ AI như hacker, duy trì red-blue team thường xuyên, giám sát liên tục, thiết lập giới hạn thiệt hại cứng để chống chịu rủi ro cực đoan và vượt qua chu kỳ ngành.

DRIFT-0,24%
ZRO-4%
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • Bình luận
  • Đăng lại
  • Retweed
Bình luận
Thêm một bình luận
Thêm một bình luận
Không có bình luận
  • Ghim