Xây dựng và vận hành đội quân kiểm thử xâm nhập tự động với sapper-v2

sapper-v2 là gì?

sapper-v2 là một hệ thống đa tác nhân tự chủ được thiết kế cho kiểm thử xâm nhập được ủy quyền. Thay vì phụ thuộc vào một tác nhân ngày càng phức tạp, hệ thống tổ chức nhiều AI thành một quân đoàn để phân chia công việc, trao đổi phát hiện và duy trì kiến thức qua các lần thay thế tác nhân.

Dự án đã giành chiến thắng ở vòng loại trực tuyến của Tencent Cloud Intelligent Attack-Defense Challenge lần thứ ba và nhận Giải Nhất trong GeekCon 2026 AI Challenge. Tại sự kiện của Tencent, hệ thống đã hoàn thành tám giờ vận hành không cần giám sát với số điểm 80.18, tìm thấy 85 flag và sử dụng khoảng một tỷ token.

Chỉ sử dụng sapper-v2 trên các hệ thống thuộc sở hữu của bạn hoặc khi bạn có quyền kiểm thử rõ ràng. Hãy xem DISCLAIMER.md trước khi cài đặt hoặc vận hành.

Cách hệ thống hoạt động

Dự án được xây dựng dựa trên ba khả năng nền tảng:

• Tạo: Hệ thống mở các phiên AI mới trong tmux, cho phép tạo các tác nhân chuyên môn khi nhiệm vụ yêu cầu.
• Ngôn ngữ: Các tác nhân giao tiếp bằng cách nhập tin nhắn vào phiên đầu vào của nhau.
• Lịch sử: Các phát hiện được lưu trữ trong một đồ thị sự kiện-mục đích phân tầng thay vì bị giữ trong ngữ cảnh của một tác nhân.

Hệ thống lịch sử có ba lớp: tiêu đề, tóm tắt và tài liệu bằng chứng. Tác nhân có thể đọc tiêu đề ngắn gọn trước, xem tóm tắt khi cần thêm ngữ cảnh và mở bằng chứng để xác minh chi tiết. Thiết kế này giảm mức tiêu thụ ngữ cảnh và hạn chế tác hại do một sự kiện không chính xác gây ra.

Các vai trò khi chạy

Khi chạy, sapper-v2 tách biệt việc điều phối, thực thi và duy trì khả dụng:

• Chỉ huy: Đọc bảng, đánh giá mục tiêu và phân công công việc. Vai trò này không tự thực hiện các cuộc tấn công.
• Tướng: Xử lý các cuộc tấn công khó và có thể tuyển các đội riêng.
• Trinh sát: Thực hiện trinh sát ngắn và giúp xác định liệu mục tiêu cần thực thi trên diện rộng hay điều tra sâu hơn.
• Binh lính: Làm việc song song trên các nhiệm vụ được giao.
• Nhân viên tín hiệu: Thu thập và gửi các flag chưa được báo cáo từ một nơi duy nhất; đây là vai trò phát sinh trong quá trình vận hành thay vì được lập trình sẵn.
• Watchdog: Một tập lệnh không có chiến lược, duy trì hệ thống hoạt động bằng cách khởi động lại chỉ huy bị lỗi với --continue, xoay vòng khóa và xử lý việc kết thúc phiên chạy.

README mô tả ba cửa sổ chạy hiển thị: chỉ huy, quân đoàn AI chạy trong các khung tmux và watchdog.

Tính năng chính

• Phân chia lao động song song: Trinh sát, binh lính, tướng và chỉ huy hoạt động với các trách nhiệm riêng biệt.
• Bộ nhớ tổ chức bền vững: Kiến thức vẫn tồn tại khi một tác nhân riêng lẻ được thay thế.
• Luân chuyển ngữ cảnh: Các tác nhân có ngữ cảnh trở nên quá tải có thể để lại bài học bằng văn bản cho những tác nhân kế nhiệm.
• Phân tầng mô hình: Cấu hình thi đấu sử dụng GLM-5.3 cho chỉ huy và các tướng, cùng DeepSeek V4.1 Flash cho trinh sát và binh lính.
• Khả năng chống gián đoạn vận hành: Watchdog có thể khởi động lại chỉ huy, xoay vòng khóa và duy trì tính liên tục mà không đưa ra quyết định chiến lược.
• Chuyển giao giữa các thử thách: Chỉ huy có thể nhận diện các nhóm thử thách tương tự về cấu trúc và truyền các quy trình xử lý thành công cho những tác nhân mới được phân công.
• CLI sự kiện-mục đích: Dự án cung cấp các lệnh và hướng dẫn để vận hành đồ thị và chạy quy trình trên nhiều thử thách.

Cài đặt CLI sapper

Trình cài đặt bắt đầu nhanh liên kết CLI sapper vào vị trí thích hợp. Theo README, CLI chỉ sử dụng thư viện chuẩn và không có phần phụ thuộc bổ sung.

Từ thư mục gốc của kho lưu trữ, chạy:

bash install.sh

README không liệt kê các điều kiện tiên quyết cục bộ bổ sung hoặc các bước cài đặt riêng cho từng nền tảng. Nếu lệnh không làm cho sapper khả dụng trong shell của bạn, hãy kiểm tra install.sh và xác nhận đích liên kết tượng trưng của nó nằm trong đường dẫn thực thi của bạn.

Bắt đầu một cuộc đánh giá được ủy quyền

Tạo một cuộc đánh giá mới bằng sapper setup. Ví dụ sau được lấy từ phần bắt đầu nhanh của dự án:

sapper setup --goal "assess http://target" --agents

Chỉ thay http://target bằng một endpoint nằm trong phạm vi ủy quyền bằng văn bản của bạn. Mục tiêu nên mô tả rõ phạm vi được phê duyệt để các tác nhân nhận được nhiệm vụ không mơ hồ.

Tùy chọn --agents khởi động quy trình dành cho tác nhân được dự án trình bày. Sau khi thiết lập, hãy kiểm tra bảng và phạm vi hiện tại:

sapper status

Chế độ xem trạng thái là lệnh bắt đầu nhanh chính để kiểm tra tiến độ công việc. Chỉ huy sử dụng bảng để đánh giá mục tiêu và phân công chuyên gia thay vì trực tiếp thực hiện các nhiệm vụ đánh giá.

Quy trình CLI tối thiểu

1. Xác minh quyền: Ghi lại mục tiêu, khung thời gian, kỹ thuật được phê duyệt và điều kiện dừng bên ngoài công cụ.
2. Cài đặt CLI: Chạy bash install.sh từ kho lưu trữ đã sao chép.
3. Xác định mục tiêu: Chạy sapper setup --goal "assess http://target" --agents với mục tiêu đã được phê duyệt.
4. Giám sát bảng: Chạy sapper status để xem lại bảng và phạm vi.
5. Xem lại kiến thức được lưu giữ: Sử dụng quy trình sự kiện-mục đích được ghi lại trong SKILL.md khi cần các thao tác trên một đồ thị hoặc quét nhiều thử thách.

Chạy toàn bộ quân đoàn bằng Docker

Kho lưu trữ bao gồm một Dockerfile dành cho toàn bộ legion dựa trên commander. Hãy xây dựng image từ thư mục gốc của kho:

docker build -f docker/Dockerfile.commander -t sapper:latest .

Trước khi khởi động container, hãy cấu hình các biến môi trường về model gateway, nhóm khóa và ngân sách được mô tả trong docker/ENV.md. Những thiết lập này rất quan trọng vì kiến trúc phân công các trách nhiệm khác nhau cho từng cấp model, đồng thời bao gồm cơ chế xoay vòng khóa và vận hành có xét đến ngân sách.

README trình bày việc khởi chạy container dưới dạng sơ đồ:

docker run -d --name sapper ... sapper:latest

Dấu ba chấm không phải là đối số literal có thể chạy ngay. Hãy thay thế chúng bằng các biến môi trường bắt buộc và những tùy chọn Docker khác trong tài liệu môi trường của kho. Không được đoán thông tin xác thực production hoặc đặt secret trực tiếp vào lịch sử shell khi đã có phương thức quản lý secret an toàn hơn.

Nắm rõ nguyên tắc của commander

Nguyên tắc vận hành của commander được lưu trong docker/commander/SKILL.md. README nhấn mạnh một số nguyên tắc:

• Lập lịch song song, ưu tiên việc dễ: Phân phối công việc để các mục tiêu dễ xử lý có thể được giải quyết đồng thời, thay vì buộc toàn bộ legion đi theo một hướng khó duy nhất.
• Tận dụng thời gian nút thắt: Gần cuối một chiến dịch, xem xét lại các mục tiêu đã được giải quyết một phần, nơi bằng chứng hiện có có thể nhanh chóng tạo ra kết quả.
• Kỷ luật giới hạn thua lỗ: Tránh dành thời gian hoặc token không giới hạn cho những công việc không tạo ra tiến triển.
• Phân tách vai trò: Dành sự tập trung của commander cho việc đọc bảng, phán đoán và điều phối, thay vì trực tiếp thực thi.

Để xem hợp đồng kiến trúc chính thức, hãy đọc docker/commander/SPEC.md. Để xem bản hồi cứu giải thích cách hệ thống hoạt động trong cuộc thi, hãy tham khảo BATTLE-REPORT.md.

Mẹo vận hành nâng cao

Viết mục tiêu phù hợp với phạm vi được cấp phép

Mục tiêu thiết lập là nhiệm vụ mà các agent hướng tới. Hãy nêu chính xác mục tiêu đã được phê duyệt và tránh cách diễn đạt rộng có thể bị hiểu là cho phép dò xét các máy chủ hoặc dịch vụ không liên quan. Các tài liệu cấp phép bên ngoài vẫn là nguồn thông tin chính thức.

Sử dụng bằng chứng theo tầng thay vì bản tóm tắt quá lớn

Giữ các thông tin cấp cao súc tích, đồng thời duy trì bằng chứng chi tiết bên dưới. Tiêu đề nên truyền đạt ý chính, phần tóm tắt nên giải thích mức độ liên quan, còn tài liệu bằng chứng phải hỗ trợ việc xác minh. Cách này tuân theo thiết kế của sapper-v2 và tránh phải nạp lặp lại mọi chi tiết vào ngữ cảnh của agent.

Bảo toàn bài học khi luân chuyển agent

Dự án đo được mức bão hòa ngữ cảnh của soldier vào khoảng 260,000 token trong chiến dịch. Cách xử lý là thay worker, đồng thời để lại playbook cho người kế nhiệm. Khi xem xét kết quả vận hành, hãy ưu tiên các ghi chú bàn giao rõ ràng, bao gồm phát hiện đã xác minh, phương pháp đã thử, câu hỏi chưa được giải quyết và quy trình có thể tái sử dụng.

Tách biệt chiến lược và tính sẵn sàng

Watchdog cố ý không có vai trò chiến lược. Hãy giữ riêng hành vi khôi phục, việc xoay vòng khóa và khởi động lại quy trình khỏi các quyết định về mục tiêu và chiến thuật. Điều này giúp dễ xác định một hành động xuất phát từ commander hay từ cơ chế tự động duy trì hoạt động.

Kiểm soát chi phí token và model

Kiến trúc thi đấu của sapper-v2 phân công các model mạnh hơn cho việc ra quyết định cấp cao và các model nhẹ hơn cho hoạt động trinh sát, thực thi với khối lượng lớn. Nếu tái tạo cấu hình được ghi lại, hãy thiết lập gateway, nhóm khóa và ngân sách thông qua hướng dẫn môi trường Docker, đồng thời theo dõi mức tiêu thụ trong suốt quá trình chạy được cấp phép.

Kiểm tra bằng chứng trước khi tin tưởng kiến thức được chuyển giao

Việc chuyển giao giữa các thử thách có thể đẩy nhanh công việc khi các mục tiêu có chung cấu trúc, nhưng sự tương đồng không thể thay thế việc xác minh. Hãy dùng đồ thị theo tầng để kiểm tra các bản tóm tắt và bằng chứng hỗ trợ trước khi áp dụng playbook kế thừa cho một thử thách khác.

An toàn và sử dụng có trách nhiệm

sapper-v2 là một công cụ bảo mật tấn công và không được sử dụng để truy cập trái phép. README cảnh báo rõ rằng AI có thể khuếch đại tác hại do các công cụ tấn công gây ra. Hãy tuân thủ luật hiện hành, có được sự cho phép rõ ràng, giới hạn phạm vi mục tiêu, thiết lập ngân sách và điều kiện dừng, đồng thời duy trì sự giám sát của con người phù hợp với môi trường.

Dự án cũng đề xuất một cơ chế taggant trong tương lai: các dấu đánh dấu gắn với một harness tấn công, có thể làm rò rỉ thông tin nhận dạng cho nạn nhân trong các cuộc xâm nhập bất hợp pháp và hỗ trợ việc quy kết nguồn gốc. README trình bày đây là một đề xuất cần thiết kế về mặt mật mã và cộng đồng, không phải biện pháp bảo vệ hiện có mà người dùng có thể dựa vào hôm nay.

Kết luận

sapper-v2 thể hiện một phương pháp hợp tác cho hoạt động đánh giá bảo mật tự động: một commander phân công công việc, các chuyên gia vận hành song song, watchdog duy trì tính liên tục và đồ thị sự kiện theo tầng bảo toàn kiến thức tổ chức. Hãy bắt đầu với CLI gọn nhẹ, theo dõi bảng bằng sapper status và sử dụng thiết lập Docker khi cần toàn bộ legion. Luôn bảo đảm mọi lần chạy đều nằm trong phạm vi được cấp phép rõ ràng và tuân thủ tuyên bố miễn trừ trách nhiệm của dự án.