Chiến dịch Gheist: Dùng token GitHub bị đánh cắp để cài workflow lén đánh cắp bí mật
Chiến dịch Gheist đang lạm dụng hàng loạt token GitHub bị đánh cắp để cài workflow độc hại vào kho mã nguồn, mã hóa bí mật sang base32 rồi tải log qua API GitHub trước khi xóa dấu vết. Wiz đã phát hiện hơn 13.500 nhánh độc hại từ hơn 850 tài khoản bị xâm phạm.

Chiến dịch Gheist: Dùng token GitHub bị đánh cắp để cài workflow lén đánh cắp bí mật
Các nhà nghiên cứu của Wiz vừa công bố phát hiện về Gheist – một chiến dịch tấn công mới lạm dụng quy mô lớn các token GitHub bị đánh cắp. Kẻ tấn công cài một workflow có tên sync-check vào mọi kho mã nguồn mà token đó có quyền truy cập, nhằm in các bí mật (secret) ra log của chính workflow rồi tải log về qua API GitHub và xóa dấu vết chỉ vài giây sau đó.
Theo Wiz, chiến dịch được theo dõi từ ngày 15/9/2026 và đã có hơn 13.500 nhánh độc hại được cài đặt từ hơn 850 tài khoản bị xâm phạm, trải rộng từ dự án cá nhân đến các kho riêng tư của tổ chức doanh nghiệp.
Cơ chế hoạt động tinh vi
Với mỗi kho mã nguồn, công cụ của kẻ tấn công tạo một nhánh có tên ci-sync- kèm sáu ký tự ngẫu nhiên, sau đó commit file .github/workflows/sync-check.yml với thông điệp ci: sync config. Sự kiện push sẽ kích hoạt workflow và đây là điểm mấu chốt của cuộc tấn công.
Ba chi tiết khiến kỹ thuật này phát huy hiệu quả:
- GitHub chỉ che giá trị bí mật trong log khi chúng xuất hiện nguyên văn. Một bí mật được mã hóa base32 sẽ không khớp mẫu che giấu, nên bị in ra đầy đủ.
- Cấu hình
permissions: {}tuy hạn chếGITHUB_TOKENcủa job nhưng không hạn chế ngữ cảnh secrets – thứ mà kẻ tấn công thực sự nhắm tới. - Khi kho có các môi trường triển khai (environment), công cụ liệt kê chúng thành một ma trận job, nhờ đó bí mật riêng theo từng môi trường – thường là thông tin xác thực production – cũng bị in ra.
Đáng chú ý, vì dữ liệu rò rỉ qua chính API của GitHub nên không có tên miền của kẻ tấn công hay kết nối ra ngoài nào để chặn. Trong các tổ chức doanh nghiệp, Wiz quan sát thấy công cụ này luân phiên token của nhiều người dùng và tài khoản tự động chỉ trong vài phút, clone các kho riêng tư trước khi cài workflow, và vài giờ sau dùng thông tin xác thực đám mây của chính tổ chức đó để liệt kê AWS Secrets Manager.
Payload liên tục tiến hóa
Wiz ghi nhận hai biến thể chạy song song, phân biệt qua tên nhánh: Tool A dùng hậu tố thập lục phân và payload đơn giản; Tool B dùng hậu tố base36, bổ sung timeout-minutes: 6 và ma trận environment chỉ trong vài giờ sau lần chạy đầu ngày 28/9.
Đến ngày 19/10, Tool B còn thêm cả một job thứ hai tên sync-host chạy trên self-hosted, nhắm vào các kho có runner tự vận hành. Job này ghi lại thông tin máy chủ, quét đệ quy 31 định dạng token – bao gồm cả khóa của các nhà cung cấp AI như Anthropic, Hugging Face, Groq, NVIDIA – cùng khóa riêng, file .env, trạng thái Terraform, lịch sử shell, biến môi trường của mọi tiến trình, và cả quyền truy cập qua Docker socket để đọc thẳng ổ đĩa máy chủ.
Tuy nhiên, job này vẫn còn lỗi: tìm sai file khóa của runner, biểu thức regex nhận diện thông tin xác thực trong URL bị hỏng và không thu thập được token GCP hay Azure.
Cơ chế phòng vệ của GitHub vẫn còn lỗ hổng
Từ ngày 28/7/2026, GitHub đã giữ các lần chạy workflow bị nghi ngờ trong kho công khai cho đến khi có người duyệt. Mọi lần chạy Gheist trên kho công khai mà Wiz kiểm tra đều nằm ở trạng thái action_required – payload độc hại chưa từng thực thi.
Thế nhưng cơ chế này không áp dụng cho kho riêng tư hay GitHub Enterprise Server. Tại đó, log kiểm toán cho thấy các lần chạy trên nhánh ci-sync-* đã hoàn tất rồi bị xóa bởi user agent gheist, còn CloudTrail ghi nhận chính workflow của tổ chức chạy trên các nhánh đó và đảm nhận vai trò AWS – bằng chứng Actions đã thực thi mà không cần phê duyệt.
Với đội ngũ phòng thủ, tín hiệu cuối cùng này giúp phát hiện Gheist mà không cần bất kỳ log GitHub nào.
Cùng một tập tài khoản, nhiều chiến dịch khác nhau
Chiến dịch này chỉ là một phần trong bức tranh lớn hơn: các tài khoản bị xâm phạm còn bị nhiều nhóm tấn công khác khai thác, cho thấy thông tin xác thực bị lộ có thể luân chuyển khắp hệ sinh thái tội phạm mạng. Wiz ghi nhận sự chồng lấn với các chiến dịch:
- Kho mã nguồn mồi nhử phát tán malware: ngày 6/10, 391 tài khoản đổi tên khoảng 1.461 kho thành các lời mời chào phần mềm bẻ khóa.
- Khai thác tính toán miễn phí: ngày 18/10, 25 tài khoản mỗi bên tạo một kho "Windows RDP Runner" trong vòng chín phút để đào tiền mã hóa.
- PolinRider: một số nạn nhân có dấu hiệu nhiễm malware liên quan Triều Tiên, giấu JavaScript trong file cấu hình build.
- Megalodon: 57 tài khoản thuộc giai đoạn đầu của Gheist từng là nạn nhân của chiến dịch này hồi tháng 5.
Các nguồn thông tin xác thực mà Wiz truy vết được gồm log của infostealer và token bị lộ trong những vụ tấn công chuỗi cung ứng trước đó, chẳng hạn vụ Trivy hồi tháng 3.
Khuyến nghị cho đội ngũ an ninh
Săn tìm dấu vết:
- Tìm các nhánh có tên
ci-sync-kèm sáu ký tự ngẫu nhiên, nơi thay đổi duy nhất là filesync-check.ymlvới thông điệp commitci: sync config. - Trong log kiểm toán GitHub, tìm các lần chạy workflow trên nhánh
ci-sync-*bị xóa trong vòng một phút sau khi hoàn tất, cùng mọi hoạt động từ user agentgheist. - Nếu workflow xác thực với đám mây qua OIDC, hãy kiểm tra log đám mây cho các lần đảm nhận vai trò có subject chứa nhánh
ci-sync-. - Trên runner tự vận hành, tìm các file
.gdmp_pat,.gdmp_patg,.gdmp_sweepvà chuỗigdmp-pivottrong log job.
Xử lý sự cố:
- Xoay vòng toàn bộ bí mật của kho, tổ chức và môi trường mà kho bị ảnh hưởng có thể truy cập – xóa lần chạy hay nhánh không hoàn tác được việc rò rỉ.
- Thu hồi các token đã push commit và kiểm tra thiết bị của chủ sở hữu chúng để tìm infostealer.
- Nếu nhánh
ci-synctừng chạy trên runner tự vận hành, hãy coi máy chủ và vai trò instance của nó đã bị xâm phạm. - Không phê duyệt các lần chạy
sync-checkđang bị giữ, không chạy mã từ nhánhci-sync.
Tăng cường phòng thủ:
- Yêu cầu người duyệt cho các môi trường chứa bí mật production.
- Giới hạn chính sách tin cậy OIDC cho nhánh hoặc môi trường được bảo vệ.
- Dùng GitHub Apps hoặc token ngắn hạn thay cho personal access token.
- Vận hành runner tự vận hành như máy chủ tạm thời, không mở Docker socket hay quyền truy cập metadata không giới hạn.
Chỉ dấu xâm phạm (IoC)
- User agent:
gheist - Nhánh:
ci-sync-kèm sáu ký tự, khớp mẫu^ci-sync-[0-9a-z]{6}$ - Thông điệp commit:
ci: sync config, chỉ thêm file.github/workflows/sync-check.yml - Dấu hiệu trong payload:
toJSON(secrets) }}' | base32 -w 120và===== gdmp-pivot: - File cần tìm:
.gdmp_pat,.gdmp_patg,.gdmp_sweep - SHA của workflow độc hại:
f3da2b8b357dcda02fd455d314be2a95007516a6(bản đơn giản),d09535857a741bbb976bdc084a9a021713133291(bản có timeout),1dc5af9cce950aad1eb1546ecce8565b117540c4(bản có dấu phân cách),c665b778b2d822453293003e7ca0bbb2cb08e39d(job self-hosted)
Với các đội ngũ DevOps tại Việt Nam đang dùng GitHub Actions cho CI/CD, đây là lời nhắc nhở rõ ràng: cần rà soát lại phạm vi quyền của token, bật bảo vệ nhánh cho các môi trường production và coi mọi nhánh lạ xuất hiện trong kho là tín hiệu cần kiểm tra ngay.
Nguồn: Wiz Research
Bài viết liên quan

Công nghệ
Context Engineering 2026: Khi nào nên để AI tự quyết và khi nào phải viết bằng code?
25 tháng 10, 2026

Công nghệ
Bản đồ tương tác 1.469 trận chiến của người La Mã: Dự án dữ liệu mở gây chú ý
25 tháng 10, 2026

Công nghệ
Đằng sau một bộ phim hoạt hình Disney: 144.355 khung hình và 5 năm làm việc
25 tháng 10, 2026