gheist-guard

Dạng tấn công mà công cụ theo dõi

Một token bị đánh cắp từ máy của một developer trở thành kênh rò rỉ secret cho cả tổ chức, mà không có tên miền lạ hay kết nối ra ngoài nào để tường lửa chặn. Kẻ tấn công đẩy một nhánh tên ci-sync- kèm sáu ký tự, commit một workflow in secret của repo dưới dạng mã hóa base32 vào log chạy (GitHub chỉ che secret khi nó xuất hiện nguyên văn), rồi tải log qua GitHub API và xóa run trong vài giây. Wiz Research đã thu hồi hơn 13.500 nhánh bị cài cắm từ hơn 850 tài khoản bị xâm phạm trong báo cáo tháng 10/2026. Cơ chế kiểm soát ngày 28/7/2026 của GitHub giữ các run đáng ngờ trong repo public để chờ cộng tác viên phê duyệt, nhưng không áp dụng cho repo private hay GitHub Enterprise Server — đúng nơi dạng tấn công này thành công. Xóa nhánh hay xóa run cũng không hủy được việc lộ: mọi secret mà run đó đọc được đều phải xoay.

“Gheist” là tên Wiz Research đặt cho chiến dịch mà họ báo cáo tháng 10/2026. Công cụ này không liên kết, không được Wiz chứng thực, và không tự nhận là công cụ đầu tiên phát hiện chiến dịch nào. Workflow rò rỉ không chứa text secret nên không công cụ quét nội dung nào phát hiện được — gheist-guard theo dõi chính hành vi, từ bằng chứng còn sót lại.

Công cụ kiểm tra gì

Tham chiếu đầy đủ các quy tắc: docs/RULES.md trong repo.

Kết luận

Mã thoát 2 nghĩa là lỗi dùng lệnh hoặc lỗi API. Luôn in một dòng tóm tắt ra stderr. Tên “Gheist” chỉ xuất hiện trong kết luận khi mẫu đầy đủ theo tài liệu khớp.

Cài đặt từ source

git clone https://github.com/techdevfun/gheist-guard.git
cd gheist-guard
npm ci
npm run build
node dist/cli.js scan <owner/repo>

Lệnh chép đúng từ README của gheist-guard (v0.1.1). Chưa dùng npm install -g gheist-guard — README ghi là “once published to npm” (khi đã publish lên npm). Cần Node 20 trở lên. Token fine-grained chỉ cần quyền đọc repo là đủ cho đường REST; truyền qua --token hoặc GITHUB_TOKEN.

Ví dụ

# Quét một repo (đường REST, chỉ đọc)
node dist/cli.js scan <owner/repo>
# Quét mọi repo trong một tổ chức (đường REST)
node dist/cli.js scan --org <org>
# Đường audit-log (cần token của organization-owner khi chạy thật;
# --events chạy với payload audit-log đã ghi lại)
node dist/cli.js audit --org <org> --events audit-events.json
# In lại checklist xoay secret từ report đã lưu, không cần quét lại
node dist/cli.js scan <owner/repo> > report.json
node dist/cli.js checklist <owner/repo> --report report.json

Automation hợp lệ có thể đưa vào allowlist và sẽ được báo là SKIPPED kèm lý do, không bao giờ bị bỏ qua âm thầm (xem README cho --allow-branch-pattern và --allow-workflow).

Checklist xoay secret (chỉ khi CONFIRMED, theo thứ tự)

1. Thu hồi token của người đẩy.
2. Xoay mọi secret mà run đó có thể đọc (chỉ liệt kê tên).
3. Kiểm tra các role OIDC có thể đảm nhận từ ref khớp.
4. Kiểm tra máy của người đẩy có bị infostealer xâm phạm không.

Checklist chỉ liệt kê tên secret. Công cụ không bao giờ in, lưu hay truyền giá trị secret, và v1 không bao giờ tự xóa, xoay hay thu hồi gì — người vận hành tự làm.

Số liệu đã đo (README, bản build 2026-10-27)

• Bộ test: 52/52 xanh (TypeScript strict, sạch).
• Kết luận trên fixture: CONFIRMED cho mọi fixture bị cài cắm; CLEAR cho mọi fixture hợp lệ; SUSPECT (không bao giờ CONFIRMED, không bao giờ âm thầm CLEAR) cho mọi fixture tín hiệu một phần.
• Thăm dò false-positive: 24 tên nhánh hợp lệ + 5 workflow hợp lệ → 0 CONFIRMED, 1 SUSPECT (ci-sync-config khớp mẫu sáu ký tự theo thiết kế; ranh giới đã ghi trong tài liệu).
• Chạy REST thật (GitHub API thật, chỉ đọc, 2026-10-27): 3 repo thật được quét, tất cả CLEAR, mã thoát 0; cộng một repo scratch private với nhánh bị cài cắm: SUSPECT trước sửa (chỉ R1) và CONFIRMED sau sửa (R1+R2+R3) trên trạng thái thật.

Đây KHÔNG phải gì — và các giới hạn

• Không phải công cụ quét secret tĩnh (đó là việc của Gitleaks/TruffleHog, ngoài phạm vi). Không phải SIEM, dịch vụ giám sát, cơ sở dữ liệu malware hay công cụ tự khắc phục.
• Không phải cơ chế ngăn chặn cho repo public: cơ chế approval hold của GitHub đã làm việc đó, và công cụ này không bao giờ phê duyệt run đang bị giữ.
• Đường audit-log mới chỉ được test end-to-end bằng fixture: không có tài khoản organization-owner để test thật. Report luôn ghi rõ đường nào đã chạy; đường REST là đường đã đo thật.
• Log site-admin của GitHub Enterprise Server đã ghi trong tài liệu nhưng chưa test (không có instance). Việc gắn pull request chỉ là xấp xỉ: commit workflow có pull request đi kèm được coi là đã review.
• Đối thủ hơn chúng ta ở đâu (từ README, nói thật): cơ chế native của GitHub hơn về thẩm quyền và vị trí; Socket, StepSecurity và GitGuardian hơn về quy mô threat intelligence; Gitleaks và TruffleHog hơn về độ rộng mẫu secret; SIEM hơn về tương quan tập trung; runbook thủ công hơn về việc dùng ngay không cần cài đặt.

Source + README trên GitHub → · Báo lỗi → · ask@techdev.fun

Công cụ liên quan

Các công cụ mã nguồn mở khác của TECHDEV: sessguard, runverdict, vetgate, context-diet, ci-failure-detective, agent-seatbelt, devsecops-os, env-doctor, skill-audit, logtrim, testguard, breakcheck, keymap, memgraph, ggufit, leaseguard, factfence, jsonfold

Đóng góp ý kiến

Bình chọn cho công cụ này, đề xuất tính năng, hoặc thảo luận với các vận hành khác trên bảng cộng đồng.