Chiến dịch GhostAction chiếm quyền tài khoản GitHub để đánh cắp bí mật CI/CD và AI

Một chiến dịch tấn công mạng có phối hợp mang tên GhostAction đã xâm nhập khoảng 1.900 tài khoản GitHub vào tháng 10 năm 2026. Tin tặc sử dụng các điểm truy cập này để chèn các workflow GitHub Actions độc hại vào hơn 30.000 kho lưu trữ, nhằm đánh cắp các thông tin đăng nhập nhạy cảm bao gồm khóa truy cập đám mây và token API của các nhà cung cấp AI.

Diễn biến sự việc

Cuộc tấn công leo thang vào ngày 8 và 9 tháng 10 năm 2026, khi các nhóm đe dọa nhắm mục tiêu vào các kho lưu trữ thuộc về khoảng 3.000 người dùng và tổ chức. Trong giai đoạn cao điểm này, các workflow độc hại đã cố gắng trích xuất 3.174 bí mật riêng biệt. GitGuardian, đơn vị theo dõi chiến dịch, ghi nhận rằng tin tặc đã triển khai mã độc theo nhiều giai đoạn. Một đợt đẩy ban đầu nhắm vào khoảng 160 tài khoản từng là nạn nhân trước đó, tiếp theo hai mươi phút sau là một đợt triển khai lớn hơn nhiều ảnh hưởng đến 28.000 kho lưu trữ mới.

Khác với các cuộc tấn công chuỗi cung ứng trước đây khai thác lỗ hổng trong các hành động chia sẻ (shared actions), chẳng hạn như vụ xâm phạm tj-actions/changed-files, GhostAction dựa vào thông tin đăng nhập của nhà phát triển bị đánh cắp. Phân tích từ StepSecurity ngày 9 tháng 10 cho thấy tin tặc có khả năng đã sử dụng các token truy cập cá nhân (personal access tokens) thu được từ các bản dump thông tin đăng nhập, mặc dù nguồn gốc ban đầu của những thông tin này vẫn chưa được xác nhận. Với quyền ghi hợp lệ, tin tặc đã trực tiếp sửa đổi các workflow của kho lưu trữ, bỏ qua nhu cầu khai thác bất kỳ lỗ hổng nào trên nền tảng GitHub Actions.

Các tệp độc hại được ngụy trang bằng những cái tên vô hại như security-audit.yml hoặc github_actions_security.yml. Các job giả mạo này tham chiếu đến những bí mật đã được sử dụng bởi các quy trình xây dựng chính thống, cho phép chúng chạy mà không gây nghi ngờ ngay lập tức trong khi âm thầm thu thập thông tin đăng nhập ở hậu trường. Các cơ chế kiểm soát phê duyệt của GitHub đã chặn nhiều workflow này, nhưng tin tặc đã thích ứng bằng cách tái sử dụng 92 workflow cũ từ các cuộc tấn công trước đó, một số trong đó đã hoạt động từ tháng 9 năm 2025.

Cơ chế hoạt động

Cơ chế cốt lõi của cuộc tấn công liên quan đến việc chèn các tệp workflow YAML thực thi các hành động checkout tiêu chuẩn với việc lấy lịch sử dữ liệu sâu. Cụ thể, các workflow sử dụng actions/checkout@v4 với tham số fetch-depth: 0. Cấu hình này chỉ thị cho runner tải xuống toàn bộ lịch sử Git thay vì chỉ commit mới nhất. Bằng cách truy cập toàn bộ lịch sử, các script độc hại có thể quét không chỉ cây làm việc hiện tại mà còn cả các commit trong quá khứ để tìm kiếm các bí mật được hardcode.

Các trình quét tìm kiếm nhiều loại thông tin đăng nhập, bao gồm khóa AWS, token truy cập cá nhân của GitHub và GitLab, khóa Google và Firebase, cùng các token API từ các nhà cung cấp AI như Anthropic, OpenAI và OpenRouter. Các phiên bản malware sau đó đã cải thiện logic trích xuất bằng cách nắm bắt các dòng mã xung quanh, cho phép chúng ghép cặp ID khóa AWS với khóa truy cập bí mật tương ứng của chúng, ngay cả khi chúng bị tách rời trong cấu trúc tệp.

Sau khi thu thập, thông tin đăng nhập được gửi qua HTTP đến máy chủ do tin tặc kiểm soát tại địa chỉ IP 193.32.204.199. Phương pháp này cho phép tin tặc truy xuất các khóa đã bị xóa khỏi mã nguồn hiện tại từ nhiều tháng hoặc nhiều năm trước nhưng vẫn còn truy cập được trong lịch sử Git. Quá trình đánh cắp diễn ra im lặng, lợi dụng môi trường thực thi hợp pháp của GitHub Actions để hòa lẫn vào lưu lượng CI/CD bình thường.

Chi tiết chính

• Khoảng 1.900 tài khoản GitHub đã bị xâm nhập để tạo điều kiện cho cuộc tấn công.
• Các workflow độc hại được chèn vào hơn 30.000 kho lưu trữ trải rộng trên 3.000 người dùng và tổ chức.
• Tin tặc nhắm mục tiêu vào 3.174 bí mật, bao gồm khóa đám mây và token API của nhà cung cấp AI.
• Các workflow sử dụng fetch-depth: 0 để quét toàn bộ lịch sử Git nhằm tìm kiếm các thông tin đăng nhập đã bị xóa trước đó.
• Dữ liệu bị đánh cắp được gửi qua HTTP tới địa chỉ IP 193.32.204.199.
• Chỉ 16% các kho lưu trữ bị ảnh hưởng từ các giai đoạn trước đó đã được dọn dẹp tính đến ngày 5 tháng 10.

Tại sao điều này quan trọng

Sự cố này làm nổi bật một điểm mù nghiêm trọng trong bảo mật phát triển hiện đại: sự tồn tại dai dẳng của các bí mật trong lịch sử Git. Nhiều đội ngũ cho rằng việc xóa một khóa được hardcode khỏi nhánh hiện tại sẽ loại bỏ rủi ro. Tuy nhiên, vì Git được thiết kế bất biến (immutable), những bí mật đó vẫn nằm trong lịch sử trừ khi chúng được xóa sạch một cách tường minh. Chiến dịch GhostAction chứng minh rằng tin tặc đang tích cực khai thác khoảng trống này, sử dụng các công cụ CI/CD tiêu chuẩn để đào lại các thông tin đăng nhập cũ mà các nhà phát triển có thể đã quên.

Đối với các lãnh đạo kỹ thuật và đội ngũ DevOps, việc phụ thuộc vào các cơ chế kiểm soát phê duyệt gốc của GitHub là không đủ. Mặc dù GitHub đã chặn nhiều lần chạy độc hại, khả năng của tin tặc trong việc tái sử dụng các workflow cũ và sử dụng thông tin đăng nhập hợp lệ đồng nghĩa với việc một số vụ đánh cắp vẫn xảy ra. Thực tế rằng chỉ 16% các kho lưu trữ bị ảnh hưởng trước đó đã được dọn dẹp vài tháng sau khi phát hiện ban đầu cho thấy sự chậm trễ đáng kể trong nỗ lực phản ứng sự cố và khắc phục trên toàn hệ sinh thái.

Hơn nữa, việc nhắm mục tiêu vào các khóa của nhà cung cấp AI báo hiệu sự thay đổi trong ưu tiên của tin tặc. Khi các công ty tích hợp nhiều dịch vụ AI hơn vào sản phẩm của mình, các token API cho những nhà cung cấp như OpenAI và Anthropic đã trở thành mục tiêu giá trị cao. Việc xâm phạm các khóa này có thể dẫn đến không chỉ tổn thất tài chính do sử dụng trái phép mà còn tiềm ẩn nguy cơ rò rỉ dữ liệu nếu các khóa đó cấp quyền truy cập vào các mô hình độc quyền hoặc dữ liệu khách hàng được xử lý bởi các dịch vụ này.

Bạn có thể làm gì

• Kiểm tra nhật ký kiểm toán GitHub và hoạt động của token truy cập cá nhân để xác định bất kỳ tài khoản nào đã sửa đổi .github/workflows/ gần đây.
• Xem xét lịch sử chạy GitHub Actions để phát hiện các hành vi bất thường.
• Rà soát toàn bộ lịch sử Git để tìm kiếm và xóa sạch các thông tin đăng nhập bị lộ.
• Áp dụng nguyên tắc đặc quyền tối thiểu (least privilege) cho các token truy cập và giảm thời hạn hiệu lực của chúng.
• Sử dụng các giải pháp quản lý bí mật chuyên dụng thay vì hardcode thông tin đăng nhập vào mã nguồn.