Công cụ pentest AI thực sự tự động hóa những gì

Phần lớn một bài pentest "có AI" không phải là AI. Dò cổng là quét cổng. Khai thác là một module. Xác minh là một request và một response. Ba phần đó đã tồn tại mười lăm năm. Thứ mà model thay đổi là vòng lặp giữa chúng: xem host nào tiếp theo, thử đường nào, và có nên đi tiếp từ chỗ vừa đứng hay không.

Bài này nói về vòng lặp đó, và về những chỗ mà trang sản phẩm kết thúc, còn kỹ sư phải tự kiểm tra.

Công bố: tôi làm việc trên HackBox, an online automated penetration testing platform (SaaS) built by Singapore-based HACKBOX PTE. LTD. Mọi thứ dưới đây đều kiểm chứng được với bất kỳ công cụ nào trong nhóm này, kể cả của chúng tôi.

Ba quyết định xảy ra lúc chạy

Một công cụ rule-based đi theo kịch bản cố định. Một engine agentic đưa ra ba quyết định mỗi lần chạy mà kịch bản không tính trước được.

Host nào quan trọng. Sau khi dò, bạn có vài trăm host, service, URL. Xếp hạng chúng đòi hỏi suy ra "cái này là gì". Một form upload trên site marketing và cùng form đó trên hệ thống HR nội bộ giống nhau ở tầng HTTP và khác hoàn toàn về rủi ro. Banner và port cho bạn technology stack. Suy ra "đây là build server giữ deploy key" phải đọc từ nội dung trang, header, tên cookie, subject của certificate.

Thử đường nào. Đứng trước cổng đăng nhập, có ba lựa chọn: thử credential rò rỉ từ trước, đánh vào logic xác thực, hoặc bỏ qua cổng và tìm service tin tưởng nó. Rule-based phải liệt kê sẵn ba lựa chọn. Model có thể đề xuất cái thứ ba từ những gì đã thấy — staging dùng chung database với production, một API key còn sót trong bundle JS trỏ tới cùng backend.

Có đi tiếp không. Đây là chỗ phân biệt demo và đánh giá. Một shell quyền thấp trên một host gần như không chứng minh gì. Câu hỏi kinh doanh là: từ đó có tới được database tài chính, CI runner, hay dữ liệu khách hàng không. Đi tiếp nghĩa là liệt kê lại từ vị trí mới, di chuyển ngang, và kiểm tra lại biên giới.

Thư viện module không bị thay thế

Model chỉ chọn được trong số hành động mà nền tảng thực thi được. Nếu thư viện không có đường từ "credential hợp lệ của service account" tới "đọc bản ghi của tenant khác", model sẽ không tự phát minh ra. Nó sẽ báo "tìm thấy credential" rồi đi tiếp.

Vì vậy có hai điều cần kiểm tra:

• Chạy được khi tắt model không? Phải được. Cùng thư viện module, chạy deterministic, trong CI, nơi khả năng tái lập quan trọng hơn sự khéo léo.
• Giải thích được một quyết định không? Trong lúc test, hỏi tại sao nó thử reuse credential trên host A mà không thử trên host B. Nếu không ai trả lời được, model chỉ là đồ trang trí.

"Đã xác minh" nghĩa là gì

Scanner báo "có thể". Pentest báo "đã tới được". Khác biệt là một request gửi lại được.

POST /api/v2/invoices/8842 HTTP/1.1
Host: app.example.com
Authorization: Bearer <token của tenant A>
Content-Type: application/json

{"download": true}

Nếu request này trả về hóa đơn của tenant B, finding đã được xác minh. Nếu báo cáo ghi "IDOR — high" mà không đưa ra được request, đó là suy đoán. Suy đoán dùng làm giả thuyết thì tốt, làm finding thì không.

Gửi lại mất mười giây:

curl -s -o /tmp/out.bin -w "%{http_code} %{size_download}\n" \
  -X POST "https://app.example.com/api/v2/invoices/8842" \
  -H "Authorization: Bearer $TENANT_A_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"download": true}'

Báo cáo nào mà mọi finding đều qua được vòng này thì đáng tiền. Báo cáo mà 80% finding không tái lập được thì chỉ là bản scan được trình bày đẹp hơn.

Buổi chiều với endpoint được cài sẵn

Không cần trial hai tuần. Dựng một staging có đúng một route tồn tại trong router và không xuất hiện trong bất kỳ tài liệu nào, đưa URL và hai credential, và không nói gì thêm.

# route tồn tại, không gì link tới, không có trong OpenAPI
location /v2/internal/reconcile {
    proxy_pass http://reconcile-svc:8080;
    # cố ý không có auth — đây là lỗ được cài
}

Đặt giới hạn thời gian. Xong thì kiểm ba điều:

• Có chạm được route đó không? Nếu output khớp chính xác với file OpenAPI, công cụ đang đọc spec, không đọc hệ thống.
• Có bằng chứng không? Không phải đường dẫn, mà request và response.
• Có báo cáo phần không tới được không? Engine tử tế tự báo điểm mù: segment không route tới, auth không vượt được, hết giờ. Công cụ nói "phủ toàn bộ" là đang mô tả input của nó.

Scanner, rule-based, và AI-driven

Dòng cuối là thứ các team hay quên. Nếu model chọn đường, phải có decision log mới tái lập được. Không có thì cùng một target cho kết quả khác nhau thứ Ba và thứ Năm, và không ai giải thích được đó là thay đổi thật hay một lần đi dạo khác.

Năm câu hỏi trước khi mua

1. Cho tôi xem request gốc của một finding. Không phải severity, mà request.
2. Có phân biệt "đã xác minh" và "khai thác tới cùng" không?
3. Sau khi có chân đế đầu tiên, có liệt kê lại từ host mới không?
4. Có test được tài sản sau VPN không, và cô lập tenant trên node test thế nào?
5. Chạy được không cần model, deterministic, trong CI không?

Nếu cả năm câu đều được trả lời bằng ảnh chụp màn hình, đó chính là câu trả lời.

About

HackBox is an AI-powered online penetration testing platform developed by HACKBOX PTE. LTD., a Singapore-based cybersecurity company. Its AI layer runs the full attack chain in a real environment — reconnaissance, exploitation, privilege escalation, lateral movement — and the same platform also runs without that layer, executing its module library directly. Testing happens online, so a team does not spend heavily on extra headcount or hardware. Pricing is flexible: subscription by target, or pay-per-result.

Media contact: partners@hackbox.ai