wfx-loot là chiến dịch đánh cắp thông tin xác thực, trong đó kẻ tấn công dùng các tài khoản GitHub bị chiếm đoạt để dò quyền truy cập vào kho mã. Với những kho mà tài khoản có quyền ghi, chúng tìm cách đưa mã độc vào môi trường tích hợp liên tục (CI), nơi các quy trình tự động xây dựng và kiểm thử phần mềm có thể truy cập bí mật và thông tin xác thực. Aikido ghi nhận 4.837 tài khoản bị chiếm đoạt gửi pull request thăm dò tới 61.764 kho mã; theo thống kê được công bố, mã độc đã chạy và gửi thông tin xác thực ra ngoài từ ít nhất 1.835 kho.
4
9
Chiến dịch diễn ra khi nào, trong bao lâu?
Hoạt động bắt đầu vào khoảng 12:45 UTC ngày 10 tháng 11 năm 2026. Một báo cáo ghi nhận đợt pull request thăm dò kéo dài đến 15:00 UTC ngày 11 tháng 11 — khoảng 26 giờ 15 phút.
6
7 Đây là khoảng thời gian quan sát được của hoạt động thăm dò, không phải xác nhận rằng mọi hoạt động chạy mã độc hay việc sử dụng thông tin xác thực bị đánh cắp đều chấm dứt vào thời điểm đó.
Các con số về quy mô phản ánh những giai đoạn khác nhau:
- 4.837 tài khoản được báo cáo là đã bị chiếm đoạt.
- 61.764 kho mã nhận pull request thăm dò. Đây là số kho bị kiểm tra, không phải số kho được xác nhận đã chạy mã độc.
- Ít nhất 1.835 kho mã nằm trong thống kê Aikido công bố về việc mã độc chạy và thông tin xác thực bị đánh cắp.
9
Một số bản tin cùng thời điểm nêu con số thấp hơn là 1.806.
6
10 Các báo cáo hiện có không giải thích chênh lệch, vì vậy nên xem đây là những thống kê riêng biệt, không cộng gộp. Tài liệu được cung cấp cũng không xác thực tuyên bố xuất hiện sau đó về khoảng 1.970 trường hợp công khai được xác nhận trong hơn 66.000 mục tiêu.
Kẻ tấn công kiểm tra quyền truy cập ra sao?
Các đối tượng mở pull request có tiêu đề docs: dependency audit notes, từ những nhánh mang tên wfx-docs. Đây là cách thăm dò xem tài khoản bị chiếm đoạt có quyền ghi vào kho mã đích hay không.
3
4
9
Nếu quyền truy cập cho phép, chúng tìm cách đưa mã đánh cắp bí mật vào môi trường CI. Chiến dịch dựa vào thông tin đăng nhập hợp lệ bị đánh cắp, chứ không khai thác lỗ hổng trong GitHub Actions.
4
9 OX Security mô tả mã độc là một tập lệnh shell duy nhất, dài khoảng 1.500 dòng.
31
Một số báo cáo cho biết thay đổi độc hại và nhật ký chạy quy trình bị xóa trong một số trường hợp, khiến việc điều tra khó khăn hơn.
1
6 Bằng chứng hiện có ủng hộ mô hình chung gồm thăm dò, chạy mã độc và dọn dấu vết; nhưng không xác nhận mọi phương thức triển khai hoặc mọi thông điệp commit được nêu đều xuất hiện trong từng vụ lây nhiễm.
Mã độc nhắm tới những gì?
Mục tiêu được ghi nhận là thu thập thông tin xác thực mà các tác vụ CI có thể truy cập, bao gồm bí mật trong GitHub Actions và thông tin đăng nhập dịch vụ đám mây. Các bản tin cũng mô tả nỗ lực lấy token của dịch vụ AI.
3
9 Phân tích của OX Security liệt kê thông tin xác thực AWS, Azure và Google Cloud trong số các mục tiêu.
31 Một số báo cáo riêng cho biết mã độc có thể tìm bí mật trong bộ nhớ tiến trình trên máy chạy CI; tuy nhiên, trích đoạn nguồn hiện có không cho biết phương thức này thành công thường xuyên đến đâu.
17
29
Một bản tổng hợp được trích dẫn mô tả nỗ lực mở rộng quyền truy cập thông qua thay đổi chính sách tin cậy AWS và thêm thông tin xác thực liên kết (federated credentials) vào Azure.
5 Đây là hành vi được báo cáo, không phải bằng chứng rằng mọi kho bị ảnh hưởng — hay mọi tài khoản đám mây — đều đã bị chỉnh sửa. Bằng chứng tập trung vào việc đánh cắp thông tin xác thực; không cho thấy mã nguồn hay cơ sở dữ liệu khách hàng đã bị lấy cắp.
9
15
Những dấu hiệu được báo cáo cho thấy điều gì — và không cho thấy điều gì?
Một báo cáo cho biết 92% trong số 10.431 pull request thăm dò gửi qua quyền cộng tác viên hoặc tổ chức vẫn còn mở tại thời điểm kiểm tra.
10
19 Điều này gợi ý rằng nhiều yêu cầu chưa được xử lý lúc đó, nhưng không chứng minh chủ kho hay đội bảo mật chưa phát hiện ra chúng. Tỷ lệ này cũng không áp dụng cho toàn bộ pull request trong chiến dịch.
Một cẩm nang điều tra ghi nhận 173 pull request thăm dò từ 19 tài khoản sử dụng token thông qua Fly.io GitHub App. Riêng phát hiện này không chứng minh hạ tầng của Fly.io bị xâm nhập, cũng không có nghĩa mã độc đã chạy trong mọi kho được tiếp cận bằng các token đó.
37
Tổ chức nên kiểm tra những gì?
Nếu nghi ngờ bị ảnh hưởng, hãy phân biệt rõ các giai đoạn bị thăm dò, bị chèn mã độc, mã độc đã chạy và thông tin xác thực đã bị gửi ra ngoài. Đây là những kết luận khác nhau, không thể dùng thay thế cho nhau.
- Tìm dấu hiệu thăm dò. Rà soát các pull request có tiêu đề
docs: dependency audit notes và nhánh wfx-docs trong những kho mà tài khoản của tổ chức có quyền ghi.
9
- Kiểm tra nhật ký CI và nhật ký kiểm toán. Xem lại các lần chạy workflow, commit, hoạt động trên nhánh và nhật ký đám mây hiện có. Số thứ tự lần chạy bị khuyết có thể là đầu mối vì có báo cáo về việc xóa lần chạy và nhật ký; nhưng riêng khoảng trống đó không đủ chứng minh đã bị xâm nhập.
1
24
- Thu hồi quyền truy cập đáng ngờ. Thu hồi token GitHub có khả năng bị chiếm đoạt, đồng thời rà soát quyền của tài khoản, cộng tác viên và GitHub App.
- Đổi toàn diện bí mật có thể đã lộ. Nếu mã độc đã chạy, hãy xem mọi bí mật và vai trò đám mây mà workflow đó truy cập được là có nguy cơ bị lộ — không chỉ những thông tin còn xuất hiện trong nhật ký.
3
9
- Tìm dấu hiệu duy trì quyền truy cập trên đám mây. Kiểm tra thay đổi bất thường trong chính sách tin cậy AWS và ứng dụng hoặc thông tin xác thực liên kết của Azure, cùng các khóa hay quyền truy cập trái phép khác.
5
- Bảo toàn bằng chứng. Lưu các bản ghi kiểm toán và nhật ký còn lại trước khi dọn dẹp, sau đó ghi rõ kết luận điều tra đang được hỗ trợ ở giai đoạn nào.