Hook
11.8 triệu USD. Đó là con số được Cơ quan Cảnh sát Singapore xác nhận trong một chiến dịch lừa đảo nhắm vào các nhà phát triển Web3. Không phải tấn công vào hợp đồng thông minh, không phải khai thác lỗi DeFi, mà là một thứ tưởng chừng đơn giản hơn: một bài kiểm tra coding giả mạo. Kẻ tấn công đã giả danh nhà tuyển dụng, mời ứng viên làm bài test, và trong quá trình đó, cài phần mềm độc hại vào máy nạn nhân. Kết quả: session token bị đánh cắp, xác thực đa yếu tố (MFA) bị vô hiệu hóa, và kho code chứa private key bị xâm nhập. Thanh khoản chết, ICO chết theo. Nhưng lần này, không phải thanh khoản chết, mà là lòng tin chết – lòng tin vào quy trình tuyển dụng của ngành crypto.
Context
Sự kiện này không đơn thuần là một vụ lừa đảo thông thường. Nó phơi bày một điểm mù trong hệ sinh thái Web3: các dự án đầu tư hàng triệu USD vào audit hợp đồng thông minh, nhưng lại bỏ qua tầng bảo mật đầu tiên – con người và quy trình. Trong bối cảnh thị trường đi ngang hiện tại, các dự án đang cắt giảm chi phí, và bảo mật nội bộ thường là khoản mục bị tinh gọn đầu tiên. Nhưng chính sự lơ là này tạo ra cơ hội cho kẻ tấn công. Theo báo cáo của Chainalysis, các cuộc tấn công xã hội (social engineering) đã chiếm hơn 50% tổng thiệt hại trong lĩnh vực crypto năm 2025. Vụ việc tại Singapore là một minh chứng điển hình: kẻ tấn công không cần kỹ năng hacking cao siêu, chỉ cần hiểu rõ quy trình tuyển dụng từ xa và khai thác lòng tin của developer. Họ đặt bẫy ngay trên LinkedIn, sử dụng tên miền giả, mô phỏng coding challenge của các dự án nổi tiếng. Khi ứng viên tải về và chạy file test, phần mềm độc hại – thường là dạng trojan truy cập từ xa (RAT) – sẽ được kích hoạt, quét bộ nhớ trình duyệt và lấy session token. Với token này, kẻ tấn công có thể truy cập vào tài khoản GitHub, GitLab, hoặc các dịch vụ CI/CD mà không cần nhập lại mật khẩu hay MFA.
Core
Bản chất kỹ thuật của vụ tấn công này là sự kết hợp giữa social engineering và supply chain attack. Cụ thể, quy trình gồm ba bước:
- Giai đoạn tiếp cận: Kẻ tấn công tạo hồ sơ giả trên LinkedIn, giả danh nhà tuyển dụng của một dự án Web3 có tiếng. Họ nhắm vào các developer có quyền truy cập vào kho code chính (main branch) hoặc nắm giữ deployment key. Bằng lời mời làm việc hấp dẫn, họ dụ ứng viên tham gia một bài kiểm tra coding trực tuyến.
- Giai đoạn lây nhiễm: File bài test thường là một kho lưu trữ (zip) chứa mã nguồn mẫu. Khi ứng viên giải nén và chạy lệnh khởi tạo (npm install, pip install, v.v.), script độc hại sẽ được thực thi. Script này có thể là một fake package (typosquatting) hoặc một đoạn mã nhúng trong file cấu hình. Nhiệm vụ của nó: quét bộ nhớ trình duyệt để tìm session cookie của các dịch vụ như GitHub, AWS, Docker Hub. Nếu tìm thấy, nó sẽ gửi cookie đó về server của kẻ tấn công.
3. Giai đoạn khai thác: Với session token hợp lệ, kẻ tấn công đăng nhập vào tài khoản GitHub của nạn nhân. Vì token đã được xác thực từ trước, MFA (thường là OTP qua SMS hoặc app) hoàn toàn bị bỏ qua. Một khi vào được kho code, chúng có thể thực hiện một trong các hành động sau: - Đọc file cấu hình chứa private key hoặc mnemonic phrase. - Thêm backdoor vào mã nguồn (ví dụ: thay đổi địa chỉ ví trong smart contract). - Kích hoạt CI/CD pipeline để deploy phiên bản độc hại lên mạng chính.
Dữ liệu từ bài kiểm tra thực tế: Trong số các vụ được báo cáo, có một trường hợp nạn nhân là developer của một DEX lớn. Kẻ tấn công đã chiếm được quyền truy cập vào kho lưu trữ private key của ví multisig, từ đó rút hết thanh khoản của pool. Thiệt hại ban đầu ước tính 2.3 triệu USD, nhưng sau đó các nhà điều tra phát hiện thêm 9.5 triệu USD từ các pool khác. Điều này cho thấy quy mô thực tế có thể lớn hơn nhiều so với con số 11.8 triệu USD được công bố.
Contrarian
Phần lớn các bài phân tích an ninh mạng hiện nay đều tập trung vào việc "nâng cao nhận thức" và "cập nhật bản vá". Nhưng tôi cho rằng đó là cách tiếp cận sai lầm. Vấn đề cốt lõi không nằm ở nhận thức của từng cá nhân, mà nằm ở cấu trúc quyền hạn và quy trình vận hành của các dự án Web3. Hãy nhìn vào thực tế: một developer mới vào được giao quyền truy cập trực tiếp vào kho code chính, thậm chí có quyền merge pull request mà không cần review. Điều này xảy ra ở hầu hết các startup Web3 vì họ muốn tăng tốc phát triển. Khi một developer làm việc trên máy tính cá nhân, không có isolation, máy đó trở thành cửa ngõ trực tiếp vào hệ thống. Vậy giải pháp không phải là "dạy developer không click vào link lạ", mà là thiết kế lại quy trình tuyển dụng và cấp quyền.

Cụ thể: - Không bao giờ cho phép chạy coding test trên máy thật. Yêu cầu ứng viên chạy trong môi trường ảo hóa hoặc container tạm thời (ví dụ: Gitpod, CodeSandbox). Nếu không thể, dự án nên cung cấp một máy ảo riêng biệt, không kết nối đến mạng nội bộ. - Áp dụng nguyên tắc least privilege ngay từ ngày đầu. Một developer mới chỉ nên có quyền đọc trên kho code, không có quyền ghi. Quyền merge chỉ được cấp sau khi có ít nhất 2 reviewer approval. - Sử dụng short-lived session token và FIDO2/Passkey thay vì OTP. OTP dễ bị phishing, trong khi Passkey gắn với thiết bị cụ thể và không thể bị đánh cắp qua session token. - Giám sát hành vi bất thường trên GitHub/GitLab. Ví dụ: nếu một user đăng nhập từ IP lạ và thực hiện clone toàn bộ repo, hệ thống nên cảnh báo ngay lập tức.

Takeaway
Sự kiện 11.8 triệu USD tại Singapore không phải là một tai nạn. Nó là hồi chuông cảnh tỉnh cho toàn bộ ngành Web3. Khi thị trường đi ngang, các dự án có xu hướng cắt giảm chi phí vận hành, và bảo mật nội bộ thường là mục đầu tiên bị cắt. Nhưng chính lúc này, kẻ tấn công lại tập trung vào các lỗ hổng phi kỹ thuật. Câu hỏi đặt ra: liệu dự án của bạn có sẵn sàng cho một cuộc tấn công tương tự? Nếu câu trả lời là "hy vọng là không", thì bạn đã sai. Hãy bắt đầu từ hôm nay: kiểm tra lại quy trình tuyển dụng, cài đặt isolation cho coding test, và thay đổi MFA từ OTP sang FIDO2. Đừng để 11.8 triệu USD trở thành bài học của bạn.