144 tool + 128 mini-tool

Dùng Burp Suite khi nhiệm vụ cụ thể là “intercept, inspect và replay HTTP/WebSocket request trong lab hoặc scope được phép” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior. Với Burp Suite, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Khi lưu kết quả từ Burp Suite, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “http-observation”: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior.
2. Dùng Burp Suite để trả lời đúng một câu hỏi thuộc nhiệm vụ “intercept, inspect và replay HTTP/WebSocket request trong lab hoặc scope được phép”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Burp Suite làm bằng chứng cuối.

Cross-check: Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Web & Proxy, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Burp Suite thành conclusion trước khi cross-check.

Dùng OWASP ZAP khi nhiệm vụ cụ thể là “proxy và automation framework cho web security testing có kiểm soát” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior. Với OWASP ZAP, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Khi lưu kết quả từ OWASP ZAP, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “http-observation”: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior.
2. Dùng OWASP ZAP để trả lời đúng một câu hỏi thuộc nhiệm vụ “proxy và automation framework cho web security testing có kiểm soát”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của OWASP ZAP làm bằng chứng cuối.

Cross-check: Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Web & Proxy, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output OWASP ZAP thành conclusion trước khi cross-check.

Dùng mitmproxy khi nhiệm vụ cụ thể là “proxy lập trình được để quan sát và biến đổi traffic của app lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior. Với mitmproxy, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Khi lưu kết quả từ mitmproxy, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “http-observation”: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior.
2. Dùng mitmproxy để trả lời đúng một câu hỏi thuộc nhiệm vụ “proxy lập trình được để quan sát và biến đổi traffic của app lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của mitmproxy làm bằng chứng cuối.

Cross-check: Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Web & Proxy, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output mitmproxy thành conclusion trước khi cross-check.

Dùng curl khi nhiệm vụ cụ thể là “tái hiện request HTTP tối thiểu và đọc header/body rõ ràng” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior. Với curl, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Khi lưu kết quả từ curl, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “http-observation”: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior.
2. Dùng curl để trả lời đúng một câu hỏi thuộc nhiệm vụ “tái hiện request HTTP tối thiểu và đọc header/body rõ ràng”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của curl làm bằng chứng cuối.

Cross-check: Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Web & Proxy, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output curl thành conclusion trước khi cross-check.

Dùng HTTPie khi nhiệm vụ cụ thể là “gửi request HTTP có cú pháp thân thiện để học API và headers” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior. Với HTTPie, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Khi lưu kết quả từ HTTPie, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “http-observation”: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior.
2. Dùng HTTPie để trả lời đúng một câu hỏi thuộc nhiệm vụ “gửi request HTTP có cú pháp thân thiện để học API và headers”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của HTTPie làm bằng chứng cuối.

Cross-check: Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Web & Proxy, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output HTTPie thành conclusion trước khi cross-check.

Dùng Chrome DevTools khi nhiệm vụ cụ thể là “quan sát Network, Storage, DOM và console của browser lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior. Với Chrome DevTools, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Khi lưu kết quả từ Chrome DevTools, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “http-observation”: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior.
2. Dùng Chrome DevTools để trả lời đúng một câu hỏi thuộc nhiệm vụ “quan sát Network, Storage, DOM và console của browser lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Chrome DevTools làm bằng chứng cuối.

Cross-check: Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Web & Proxy, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Chrome DevTools thành conclusion trước khi cross-check.

Dùng Postman khi nhiệm vụ cụ thể là “lưu collection request và environment cho API test có tổ chức” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior. Với Postman, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Khi lưu kết quả từ Postman, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “http-observation”: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior.
2. Dùng Postman để trả lời đúng một câu hỏi thuộc nhiệm vụ “lưu collection request và environment cho API test có tổ chức”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Postman làm bằng chứng cuối.

Cross-check: Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Web & Proxy, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Postman thành conclusion trước khi cross-check.

Dùng Insomnia khi nhiệm vụ cụ thể là “client API để gửi REST/GraphQL/gRPC request trong môi trường test” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior. Với Insomnia, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Khi lưu kết quả từ Insomnia, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “http-observation”: Raw HTTP/WebSocket traffic từ localhost hoặc ứng dụng nằm trong scope, kèm account test, baseline request và expected behavior.
2. Dùng Insomnia để trả lời đúng một câu hỏi thuộc nhiệm vụ “client API để gửi REST/GraphQL/gRPC request trong môi trường test”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Request/response đã lưu, headers/cookies/status, timing cơ bản, history/replay hoặc DOM/network evidence tùy tool. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Insomnia làm bằng chứng cuối.

Cross-check: Đối chiếu ít nhất một request bằng browser DevTools hoặc client HTTP thứ hai; xác nhận server-side state chứ không chỉ nhìn UI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Web & Proxy, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Insomnia thành conclusion trước khi cross-check.

Dùng Nmap khi nhiệm vụ cụ thể là “inventory host/service trong mạng lab hoặc phạm vi mạng được ủy quyền” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy. Với Nmap, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Khi lưu kết quả từ Nmap, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “authorized-inventory”: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy.
2. Dùng Nmap để trả lời đúng một câu hỏi thuộc nhiệm vụ “inventory host/service trong mạng lab hoặc phạm vi mạng được ủy quyền”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Nmap làm bằng chứng cuối.

Cross-check: Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Recon & Asset Mapping, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Nmap thành conclusion trước khi cross-check.

Dùng naabu khi nhiệm vụ cụ thể là “port discovery nhanh cho danh sách host thuộc lab hoặc scope được phép” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy. Với naabu, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Khi lưu kết quả từ naabu, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “authorized-inventory”: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy.
2. Dùng naabu để trả lời đúng một câu hỏi thuộc nhiệm vụ “port discovery nhanh cho danh sách host thuộc lab hoặc scope được phép”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của naabu làm bằng chứng cuối.

Cross-check: Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Recon & Asset Mapping, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output naabu thành conclusion trước khi cross-check.

Dùng subfinder khi nhiệm vụ cụ thể là “thu thập subdomain từ nguồn passive cho domain lab hoặc domain được phép nghiên cứu” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy. Với subfinder, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Khi lưu kết quả từ subfinder, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “authorized-inventory”: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy.
2. Dùng subfinder để trả lời đúng một câu hỏi thuộc nhiệm vụ “thu thập subdomain từ nguồn passive cho domain lab hoặc domain được phép nghiên cứu”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của subfinder làm bằng chứng cuối.

Cross-check: Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Recon & Asset Mapping, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output subfinder thành conclusion trước khi cross-check.

Dùng dnsx khi nhiệm vụ cụ thể là “resolve và kiểm tra DNS record từ danh sách hostname có kiểm soát” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy. Với dnsx, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Khi lưu kết quả từ dnsx, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “authorized-inventory”: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy.
2. Dùng dnsx để trả lời đúng một câu hỏi thuộc nhiệm vụ “resolve và kiểm tra DNS record từ danh sách hostname có kiểm soát”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của dnsx làm bằng chứng cuối.

Cross-check: Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Recon & Asset Mapping, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output dnsx thành conclusion trước khi cross-check.

Dùng httpx khi nhiệm vụ cụ thể là “probe HTTP metadata từ danh sách URL/host trong scope” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy. Với httpx, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Khi lưu kết quả từ httpx, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “authorized-inventory”: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy.
2. Dùng httpx để trả lời đúng một câu hỏi thuộc nhiệm vụ “probe HTTP metadata từ danh sách URL/host trong scope”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của httpx làm bằng chứng cuối.

Cross-check: Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Recon & Asset Mapping, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output httpx thành conclusion trước khi cross-check.

Dùng katana khi nhiệm vụ cụ thể là “crawl endpoint/form trong web lab và xuất kết quả có cấu trúc” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy. Với katana, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Khi lưu kết quả từ katana, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “authorized-inventory”: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy.
2. Dùng katana để trả lời đúng một câu hỏi thuộc nhiệm vụ “crawl endpoint/form trong web lab và xuất kết quả có cấu trúc”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của katana làm bằng chứng cuối.

Cross-check: Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Recon & Asset Mapping, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output katana thành conclusion trước khi cross-check.

Dùng gau khi nhiệm vụ cụ thể là “gom URL lịch sử/public để inventory bề mặt web đã biết” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy. Với gau, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Khi lưu kết quả từ gau, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “authorized-inventory”: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy.
2. Dùng gau để trả lời đúng một câu hỏi thuộc nhiệm vụ “gom URL lịch sử/public để inventory bề mặt web đã biết”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của gau làm bằng chứng cuối.

Cross-check: Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Recon & Asset Mapping, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output gau thành conclusion trước khi cross-check.

Dùng Amass khi nhiệm vụ cụ thể là “asset discovery và DNS relationship mapping cho lab/authorized scope” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy. Với Amass, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Khi lưu kết quả từ Amass, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “authorized-inventory”: Seed domain/host/CIDR thuộc lab hoặc authorized scope, scope note và giới hạn host/query rõ ràng trước khi chạy.
2. Dùng Amass để trả lời đúng một câu hỏi thuộc nhiệm vụ “asset discovery và DNS relationship mapping cho lab/authorized scope”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Danh sách hostname, DNS record, port/service hoặc HTTP metadata có provenance và timestamp để làm inventory. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Amass làm bằng chứng cuối.

Cross-check: Xác minh sample kết quả bằng DNS lookup/HTTP HEAD hoặc nguồn inventory khác; loại wildcard, stale record và host ngoài scope. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Recon & Asset Mapping, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Amass thành conclusion trước khi cross-check.

Dùng Nuclei khi nhiệm vụ cụ thể là “chạy template kiểm tra có kiểm soát và luôn xác minh finding thủ công” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ. Với Nuclei, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Khi lưu kết quả từ Nuclei, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “bounded-discovery”: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ.
2. Dùng Nuclei để trả lời đúng một câu hỏi thuộc nhiệm vụ “chạy template kiểm tra có kiểm soát và luôn xác minh finding thủ công”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Nuclei làm bằng chứng cuối.

Cross-check: Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Discovery & Fuzzing, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Nuclei thành conclusion trước khi cross-check.

Dùng ffuf khi nhiệm vụ cụ thể là “fuzz path/parameter trên localhost hoặc target nằm rõ trong scope” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ. Với ffuf, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Khi lưu kết quả từ ffuf, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “bounded-discovery”: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ.
2. Dùng ffuf để trả lời đúng một câu hỏi thuộc nhiệm vụ “fuzz path/parameter trên localhost hoặc target nằm rõ trong scope”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của ffuf làm bằng chứng cuối.

Cross-check: Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Discovery & Fuzzing, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output ffuf thành conclusion trước khi cross-check.

Dùng feroxbuster khi nhiệm vụ cụ thể là “content discovery cho web lab với recursion có giới hạn” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ. Với feroxbuster, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Khi lưu kết quả từ feroxbuster, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “bounded-discovery”: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ.
2. Dùng feroxbuster để trả lời đúng một câu hỏi thuộc nhiệm vụ “content discovery cho web lab với recursion có giới hạn”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của feroxbuster làm bằng chứng cuối.

Cross-check: Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Discovery & Fuzzing, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output feroxbuster thành conclusion trước khi cross-check.

Dùng dirsearch khi nhiệm vụ cụ thể là “enumerate content path trong ứng dụng test được ủy quyền” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ. Với dirsearch, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Khi lưu kết quả từ dirsearch, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “bounded-discovery”: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ.
2. Dùng dirsearch để trả lời đúng một câu hỏi thuộc nhiệm vụ “enumerate content path trong ứng dụng test được ủy quyền”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của dirsearch làm bằng chứng cuối.

Cross-check: Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Discovery & Fuzzing, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output dirsearch thành conclusion trước khi cross-check.

Dùng Gobuster khi nhiệm vụ cụ thể là “wordlist discovery cho path/DNS trong lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ. Với Gobuster, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Khi lưu kết quả từ Gobuster, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “bounded-discovery”: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ.
2. Dùng Gobuster để trả lời đúng một câu hỏi thuộc nhiệm vụ “wordlist discovery cho path/DNS trong lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Gobuster làm bằng chứng cuối.

Cross-check: Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Discovery & Fuzzing, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Gobuster thành conclusion trước khi cross-check.

Dùng Wfuzz khi nhiệm vụ cụ thể là “fuzz request field với dataset nhỏ, rate được kiểm soát trong lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ. Với Wfuzz, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Khi lưu kết quả từ Wfuzz, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “bounded-discovery”: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ.
2. Dùng Wfuzz để trả lời đúng một câu hỏi thuộc nhiệm vụ “fuzz request field với dataset nhỏ, rate được kiểm soát trong lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Wfuzz làm bằng chứng cuối.

Cross-check: Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Discovery & Fuzzing, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Wfuzz thành conclusion trước khi cross-check.

Dùng boofuzz khi nhiệm vụ cụ thể là “protocol fuzzing cho service tự dựng hoặc chương trình test” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ. Với boofuzz, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Khi lưu kết quả từ boofuzz, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “bounded-discovery”: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ.
2. Dùng boofuzz để trả lời đúng một câu hỏi thuộc nhiệm vụ “protocol fuzzing cho service tự dựng hoặc chương trình test”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của boofuzz làm bằng chứng cuối.

Cross-check: Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Discovery & Fuzzing, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output boofuzz thành conclusion trước khi cross-check.

Dùng Radamsa khi nhiệm vụ cụ thể là “mutation fuzzing trên file/input offline để tạo test cases” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ. Với Radamsa, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Khi lưu kết quả từ Radamsa, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “bounded-discovery”: Endpoint localhost/authorized scope, wordlist nhỏ, request budget và stop condition; không bắt đầu bằng wordlist khổng lồ.
2. Dùng Radamsa để trả lời đúng một câu hỏi thuộc nhiệm vụ “mutation fuzzing trên file/input offline để tạo test cases”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate path/parameter/input cùng status, size, redirect hoặc response signature để manual review. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Radamsa làm bằng chứng cuối.

Cross-check: Replay candidate bằng request tối thiểu và so với baseline/404 control để tránh coi noise, soft-404 hoặc WAF response là finding. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Discovery & Fuzzing, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Radamsa thành conclusion trước khi cross-check.

Dùng Wireshark khi nhiệm vụ cụ thể là “đọc packet capture bằng GUI và phân tích protocol/timeline từ PCAP” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture. Với Wireshark, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Khi lưu kết quả từ Wireshark, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “packet-evidence”: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture.
2. Dùng Wireshark để trả lời đúng một câu hỏi thuộc nhiệm vụ “đọc packet capture bằng GUI và phân tích protocol/timeline từ PCAP”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Wireshark làm bằng chứng cuối.

Cross-check: Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Network & PCAP, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Wireshark thành conclusion trước khi cross-check.

Dùng TShark khi nhiệm vụ cụ thể là “lọc và trích packet fields từ PCAP bằng command line” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture. Với TShark, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Khi lưu kết quả từ TShark, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “packet-evidence”: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture.
2. Dùng TShark để trả lời đúng một câu hỏi thuộc nhiệm vụ “lọc và trích packet fields từ PCAP bằng command line”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của TShark làm bằng chứng cuối.

Cross-check: Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Network & PCAP, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output TShark thành conclusion trước khi cross-check.

Dùng tcpdump khi nhiệm vụ cụ thể là “capture hoặc đọc traffic trong lab và lọc nhanh theo host/port/protocol” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture. Với tcpdump, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Khi lưu kết quả từ tcpdump, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “packet-evidence”: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture.
2. Dùng tcpdump để trả lời đúng một câu hỏi thuộc nhiệm vụ “capture hoặc đọc traffic trong lab và lọc nhanh theo host/port/protocol”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của tcpdump làm bằng chứng cuối.

Cross-check: Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Network & PCAP, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output tcpdump thành conclusion trước khi cross-check.

Dùng Zeek khi nhiệm vụ cụ thể là “chuyển traffic lab thành log mức ứng dụng để hunting và điều tra” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture. Với Zeek, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Khi lưu kết quả từ Zeek, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “packet-evidence”: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture.
2. Dùng Zeek để trả lời đúng một câu hỏi thuộc nhiệm vụ “chuyển traffic lab thành log mức ứng dụng để hunting và điều tra”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Zeek làm bằng chứng cuối.

Cross-check: Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Network & PCAP, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Zeek thành conclusion trước khi cross-check.

Dùng Suricata khi nhiệm vụ cụ thể là “IDS/NSM engine để chạy rule trên traffic lab hoặc PCAP offline” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture. Với Suricata, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Khi lưu kết quả từ Suricata, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “packet-evidence”: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture.
2. Dùng Suricata để trả lời đúng một câu hỏi thuộc nhiệm vụ “IDS/NSM engine để chạy rule trên traffic lab hoặc PCAP offline”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Suricata làm bằng chứng cuối.

Cross-check: Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Network & PCAP, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Suricata thành conclusion trước khi cross-check.

Dùng Scapy khi nhiệm vụ cụ thể là “tạo và parse packet synthetic bằng Python cho bài học protocol” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture. Với Scapy, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Khi lưu kết quả từ Scapy, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “packet-evidence”: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture.
2. Dùng Scapy để trả lời đúng một câu hỏi thuộc nhiệm vụ “tạo và parse packet synthetic bằng Python cho bài học protocol”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Scapy làm bằng chứng cuối.

Cross-check: Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Network & PCAP, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Scapy thành conclusion trước khi cross-check.

Dùng socat khi nhiệm vụ cụ thể là “nối stream/socket trong localhost lab để dựng service test và debug” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture. Với socat, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Khi lưu kết quả từ socat, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “packet-evidence”: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture.
2. Dùng socat để trả lời đúng một câu hỏi thuộc nhiệm vụ “nối stream/socket trong localhost lab để dựng service test và debug”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của socat làm bằng chứng cuối.

Cross-check: Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Network & PCAP, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output socat thành conclusion trước khi cross-check.

Dùng netcat khi nhiệm vụ cụ thể là “client/server TCP/UDP tối giản cho localhost lab và kiểm tra protocol cơ bản” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture. Với netcat, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Khi lưu kết quả từ netcat, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “packet-evidence”: PCAP offline hoặc traffic lab được phép, filter hypothesis, topology/IP/port context và timezone của capture.
2. Dùng netcat để trả lời đúng một câu hỏi thuộc nhiệm vụ “client/server TCP/UDP tối giản cho localhost lab và kiểm tra protocol cơ bản”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Packet/flow fields, DNS/TLS/protocol metadata, stream/timeline hoặc IDS log có thể trace về packet gốc. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của netcat làm bằng chứng cuối.

Cross-check: Đối chiếu packet number/timestamp và cùng field bằng tool thứ hai như Wireshark↔TShark; không kết luận chỉ từ màu/label GUI. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Network & PCAP, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output netcat thành conclusion trước khi cross-check.

Dùng jq khi nhiệm vụ cụ thể là “lọc và biến đổi JSON từ API/log/artifact một cách tái hiện được” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction. Với jq, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Khi lưu kết quả từ jq, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “structured-api-data”: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction.
2. Dùng jq để trả lời đúng một câu hỏi thuộc nhiệm vụ “lọc và biến đổi JSON từ API/log/artifact một cách tái hiện được”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của jq làm bằng chứng cuối.

Cross-check: So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm API & Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output jq thành conclusion trước khi cross-check.

Dùng yq khi nhiệm vụ cụ thể là “đọc và chỉnh YAML cấu hình lab tương tự jq cho JSON” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction. Với yq, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Khi lưu kết quả từ yq, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “structured-api-data”: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction.
2. Dùng yq để trả lời đúng một câu hỏi thuộc nhiệm vụ “đọc và chỉnh YAML cấu hình lab tương tự jq cho JSON”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của yq làm bằng chứng cuối.

Cross-check: So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm API & Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output yq thành conclusion trước khi cross-check.

Dùng grpcurl khi nhiệm vụ cụ thể là “gọi gRPC service lab và inspect method/response” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction. Với grpcurl, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Khi lưu kết quả từ grpcurl, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “structured-api-data”: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction.
2. Dùng grpcurl để trả lời đúng một câu hỏi thuộc nhiệm vụ “gọi gRPC service lab và inspect method/response”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của grpcurl làm bằng chứng cuối.

Cross-check: So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm API & Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output grpcurl thành conclusion trước khi cross-check.

Dùng websocat khi nhiệm vụ cụ thể là “kết nối WebSocket service localhost để quan sát message flow” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction. Với websocat, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Khi lưu kết quả từ websocat, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “structured-api-data”: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction.
2. Dùng websocat để trả lời đúng một câu hỏi thuộc nhiệm vụ “kết nối WebSocket service localhost để quan sát message flow”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của websocat làm bằng chứng cuối.

Cross-check: So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm API & Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output websocat thành conclusion trước khi cross-check.

Dùng GraphQL Voyager khi nhiệm vụ cụ thể là “trực quan hóa GraphQL schema đã được cung cấp trong lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction. Với GraphQL Voyager, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Khi lưu kết quả từ GraphQL Voyager, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “structured-api-data”: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction.
2. Dùng GraphQL Voyager để trả lời đúng một câu hỏi thuộc nhiệm vụ “trực quan hóa GraphQL schema đã được cung cấp trong lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của GraphQL Voyager làm bằng chứng cuối.

Cross-check: So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm API & Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output GraphQL Voyager thành conclusion trước khi cross-check.

Dùng InQL khi nhiệm vụ cụ thể là “hỗ trợ inspect/query GraphQL trong lab và Burp workflow” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction. Với InQL, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Khi lưu kết quả từ InQL, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “structured-api-data”: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction.
2. Dùng InQL để trả lời đúng một câu hỏi thuộc nhiệm vụ “hỗ trợ inspect/query GraphQL trong lab và Burp workflow”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của InQL làm bằng chứng cuối.

Cross-check: So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm API & Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output InQL thành conclusion trước khi cross-check.

Dùng Arjun khi nhiệm vụ cụ thể là “parameter discovery có giới hạn trên endpoint lab/authorized scope” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction. Với Arjun, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Khi lưu kết quả từ Arjun, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “structured-api-data”: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction.
2. Dùng Arjun để trả lời đúng một câu hỏi thuộc nhiệm vụ “parameter discovery có giới hạn trên endpoint lab/authorized scope”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Arjun làm bằng chứng cuối.

Cross-check: So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm API & Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Arjun thành conclusion trước khi cross-check.

Dùng Kiterunner khi nhiệm vụ cụ thể là “route/API discovery với wordlist trên ứng dụng test được phép” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction. Với Kiterunner, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Khi lưu kết quả từ Kiterunner, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “structured-api-data”: JSON/YAML/API request synthetic hoặc endpoint lab, schema/expected fields và auth context đã redaction.
2. Dùng Kiterunner để trả lời đúng một câu hỏi thuộc nhiệm vụ “route/API discovery với wordlist trên ứng dụng test được phép”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Structured response, transformed fields, schema/method result hoặc diff có thể lưu và rerun. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Kiterunner làm bằng chứng cuối.

Cross-check: So output với raw payload và một parser/client khác; với API phải xác nhận side effect/state chứ không chỉ status code. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm API & Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Kiterunner thành conclusion trước khi cross-check.

Dùng strace khi nhiệm vụ cụ thể là “quan sát system call của process local để debug file/network/process behavior” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác. Với strace, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Khi lưu kết quả từ strace, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “linux-state”: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác.
2. Dùng strace để trả lời đúng một câu hỏi thuộc nhiệm vụ “quan sát system call của process local để debug file/network/process behavior”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của strace làm bằng chứng cuối.

Cross-check: Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Linux & Host, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output strace thành conclusion trước khi cross-check.

Dùng ltrace khi nhiệm vụ cụ thể là “quan sát library call của chương trình local khi học runtime behavior” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác. Với ltrace, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Khi lưu kết quả từ ltrace, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “linux-state”: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác.
2. Dùng ltrace để trả lời đúng một câu hỏi thuộc nhiệm vụ “quan sát library call của chương trình local khi học runtime behavior”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của ltrace làm bằng chứng cuối.

Cross-check: Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Linux & Host, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output ltrace thành conclusion trước khi cross-check.

Dùng ss khi nhiệm vụ cụ thể là “đọc socket/listener/connection state trên Linux lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác. Với ss, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Khi lưu kết quả từ ss, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “linux-state”: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác.
2. Dùng ss để trả lời đúng một câu hỏi thuộc nhiệm vụ “đọc socket/listener/connection state trên Linux lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của ss làm bằng chứng cuối.

Cross-check: Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Linux & Host, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output ss thành conclusion trước khi cross-check.

Dùng lsof khi nhiệm vụ cụ thể là “map process với file/socket đang mở trong máy lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác. Với lsof, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Khi lưu kết quả từ lsof, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “linux-state”: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác.
2. Dùng lsof để trả lời đúng một câu hỏi thuộc nhiệm vụ “map process với file/socket đang mở trong máy lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của lsof làm bằng chứng cuối.

Cross-check: Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Linux & Host, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output lsof thành conclusion trước khi cross-check.

Dùng systemctl khi nhiệm vụ cụ thể là “xem trạng thái và quản lý service trong VM/container lab của chính mình” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác. Với systemctl, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Khi lưu kết quả từ systemctl, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “linux-state”: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác.
2. Dùng systemctl để trả lời đúng một câu hỏi thuộc nhiệm vụ “xem trạng thái và quản lý service trong VM/container lab của chính mình”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của systemctl làm bằng chứng cuối.

Cross-check: Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Linux & Host, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output systemctl thành conclusion trước khi cross-check.

Dùng journalctl khi nhiệm vụ cụ thể là “lọc systemd journal để dựng timeline và debug service” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác. Với journalctl, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Khi lưu kết quả từ journalctl, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “linux-state”: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác.
2. Dùng journalctl để trả lời đúng một câu hỏi thuộc nhiệm vụ “lọc systemd journal để dựng timeline và debug service”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của journalctl làm bằng chứng cuối.

Cross-check: Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Linux & Host, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output journalctl thành conclusion trước khi cross-check.

Dùng auditd khi nhiệm vụ cụ thể là “ghi audit event trên Linux lab để học detection/evidence” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác. Với auditd, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Khi lưu kết quả từ auditd, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “linux-state”: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác.
2. Dùng auditd để trả lời đúng một câu hỏi thuộc nhiệm vụ “ghi audit event trên Linux lab để học detection/evidence”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của auditd làm bằng chứng cuối.

Cross-check: Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Linux & Host, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output auditd thành conclusion trước khi cross-check.

Dùng osquery khi nhiệm vụ cụ thể là “query host state như bảng dữ liệu để inventory và hunting trên endpoint lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác. Với osquery, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Khi lưu kết quả từ osquery, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “linux-state”: VM/container lab, user hiện tại, process/service/file mục tiêu và snapshot/expected state trước thao tác.
2. Dùng osquery để trả lời đúng một câu hỏi thuộc nhiệm vụ “query host state như bảng dữ liệu để inventory và hunting trên endpoint lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process, socket, syscall, permission, journal/audit hoặc service state gắn với path/PID/timestamp cụ thể. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của osquery làm bằng chứng cuối.

Cross-check: Cross-check PID/user/path bằng ít nhất hai nguồn host state và xác nhận trước/sau thay đổi trên VM lab. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Linux & Host, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output osquery thành conclusion trước khi cross-check.

Dùng Process Explorer khi nhiệm vụ cụ thể là “xem process tree, signer, handles và properties trên Windows lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng. Với Process Explorer, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Khi lưu kết quả từ Process Explorer, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “windows-telemetry”: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng.
2. Dùng Process Explorer để trả lời đúng một câu hỏi thuộc nhiệm vụ “xem process tree, signer, handles và properties trên Windows lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Process Explorer làm bằng chứng cuối.

Cross-check: Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Windows & Endpoint, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Process Explorer thành conclusion trước khi cross-check.

Dùng Process Monitor khi nhiệm vụ cụ thể là “theo dõi file/registry/process activity trên Windows lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng. Với Process Monitor, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Khi lưu kết quả từ Process Monitor, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “windows-telemetry”: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng.
2. Dùng Process Monitor để trả lời đúng một câu hỏi thuộc nhiệm vụ “theo dõi file/registry/process activity trên Windows lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Process Monitor làm bằng chứng cuối.

Cross-check: Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Windows & Endpoint, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Process Monitor thành conclusion trước khi cross-check.

Dùng Autoruns khi nhiệm vụ cụ thể là “inventory persistence/startup locations để review cấu hình endpoint” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng. Với Autoruns, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Khi lưu kết quả từ Autoruns, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “windows-telemetry”: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng.
2. Dùng Autoruns để trả lời đúng một câu hỏi thuộc nhiệm vụ “inventory persistence/startup locations để review cấu hình endpoint”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Autoruns làm bằng chứng cuối.

Cross-check: Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Windows & Endpoint, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Autoruns thành conclusion trước khi cross-check.

Dùng TCPView khi nhiệm vụ cụ thể là “map Windows process với TCP/UDP endpoints đang hoạt động” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng. Với TCPView, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Khi lưu kết quả từ TCPView, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “windows-telemetry”: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng.
2. Dùng TCPView để trả lời đúng một câu hỏi thuộc nhiệm vụ “map Windows process với TCP/UDP endpoints đang hoạt động”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của TCPView làm bằng chứng cuối.

Cross-check: Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Windows & Endpoint, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output TCPView thành conclusion trước khi cross-check.

Dùng PowerShell khi nhiệm vụ cụ thể là “automation và query object Windows theo cách có thể kiểm tra lại” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng. Với PowerShell, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Khi lưu kết quả từ PowerShell, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “windows-telemetry”: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng.
2. Dùng PowerShell để trả lời đúng một câu hỏi thuộc nhiệm vụ “automation và query object Windows theo cách có thể kiểm tra lại”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của PowerShell làm bằng chứng cuối.

Cross-check: Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Windows & Endpoint, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output PowerShell thành conclusion trước khi cross-check.

Dùng Sysmon khi nhiệm vụ cụ thể là “tạo endpoint telemetry chi tiết cho detection lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng. Với Sysmon, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Khi lưu kết quả từ Sysmon, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “windows-telemetry”: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng.
2. Dùng Sysmon để trả lời đúng một câu hỏi thuộc nhiệm vụ “tạo endpoint telemetry chi tiết cho detection lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Sysmon làm bằng chứng cuối.

Cross-check: Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Windows & Endpoint, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Sysmon thành conclusion trước khi cross-check.

Dùng Event Viewer khi nhiệm vụ cụ thể là “đọc Windows Event Logs và event metadata trong investigation lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng. Với Event Viewer, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Khi lưu kết quả từ Event Viewer, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “windows-telemetry”: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng.
2. Dùng Event Viewer để trả lời đúng một câu hỏi thuộc nhiệm vụ “đọc Windows Event Logs và event metadata trong investigation lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Event Viewer làm bằng chứng cuối.

Cross-check: Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Windows & Endpoint, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Event Viewer thành conclusion trước khi cross-check.

Dùng Velociraptor khi nhiệm vụ cụ thể là “endpoint collection/hunting trên lab hoặc fleet được quản trị hợp pháp” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng. Với Velociraptor, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Khi lưu kết quả từ Velociraptor, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “windows-telemetry”: Windows VM lab, process/service/account fixture, event log hoặc Sysinternals capture với mốc thời gian rõ ràng.
2. Dùng Velociraptor để trả lời đúng một câu hỏi thuộc nhiệm vụ “endpoint collection/hunting trên lab hoặc fleet được quản trị hợp pháp”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Process tree, handle/registry/file/network event, signer, service hoặc event metadata gắn với PID/SID/time. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Velociraptor làm bằng chứng cuối.

Cross-check: Đối chiếu Process Explorer/Procmon/Event Log hoặc PowerShell query; giữ raw event ID/field thay vì chỉ screenshot. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Windows & Endpoint, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Velociraptor thành conclusion trước khi cross-check.

Dùng AWS CLI khi nhiệm vụ cụ thể là “query cấu hình/resource AWS lab bằng identity được cấp riêng cho bài học” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng. Với AWS CLI, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Khi lưu kết quả từ AWS CLI, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “cloud-control-plane”: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng.
2. Dùng AWS CLI để trả lời đúng một câu hỏi thuộc nhiệm vụ “query cấu hình/resource AWS lab bằng identity được cấp riêng cho bài học”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của AWS CLI làm bằng chứng cuối.

Cross-check: Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Cloud & IAM, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output AWS CLI thành conclusion trước khi cross-check.

Dùng Azure CLI khi nhiệm vụ cụ thể là “query Azure resource/identity trong subscription lab hoặc môi trường được phép” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng. Với Azure CLI, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Khi lưu kết quả từ Azure CLI, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “cloud-control-plane”: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng.
2. Dùng Azure CLI để trả lời đúng một câu hỏi thuộc nhiệm vụ “query Azure resource/identity trong subscription lab hoặc môi trường được phép”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Azure CLI làm bằng chứng cuối.

Cross-check: Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Cloud & IAM, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Azure CLI thành conclusion trước khi cross-check.

Dùng gcloud CLI khi nhiệm vụ cụ thể là “query Google Cloud resource/policy trong project lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng. Với gcloud CLI, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Khi lưu kết quả từ gcloud CLI, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “cloud-control-plane”: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng.
2. Dùng gcloud CLI để trả lời đúng một câu hỏi thuộc nhiệm vụ “query Google Cloud resource/policy trong project lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của gcloud CLI làm bằng chứng cuối.

Cross-check: Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Cloud & IAM, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output gcloud CLI thành conclusion trước khi cross-check.

Dùng ScoutSuite khi nhiệm vụ cụ thể là “đánh giá cấu hình cloud account lab và xuất report để review thủ công” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng. Với ScoutSuite, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Khi lưu kết quả từ ScoutSuite, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “cloud-control-plane”: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng.
2. Dùng ScoutSuite để trả lời đúng một câu hỏi thuộc nhiệm vụ “đánh giá cấu hình cloud account lab và xuất report để review thủ công”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của ScoutSuite làm bằng chứng cuối.

Cross-check: Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Cloud & IAM, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output ScoutSuite thành conclusion trước khi cross-check.

Dùng Prowler khi nhiệm vụ cụ thể là “kiểm tra security/compliance configuration của cloud lab và cần xác minh context” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng. Với Prowler, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Khi lưu kết quả từ Prowler, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “cloud-control-plane”: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng.
2. Dùng Prowler để trả lời đúng một câu hỏi thuộc nhiệm vụ “kiểm tra security/compliance configuration của cloud lab và cần xác minh context”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Prowler làm bằng chứng cuối.

Cross-check: Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Cloud & IAM, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Prowler thành conclusion trước khi cross-check.

Dùng Trivy khi nhiệm vụ cụ thể là “scan image/filesystem/config/IaC offline hoặc trong CI lab để tìm issue có thể review” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng. Với Trivy, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Khi lưu kết quả từ Trivy, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “cloud-control-plane”: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng.
2. Dùng Trivy để trả lời đúng một câu hỏi thuộc nhiệm vụ “scan image/filesystem/config/IaC offline hoặc trong CI lab để tìm issue có thể review”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Trivy làm bằng chứng cuối.

Cross-check: Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Cloud & IAM, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Trivy thành conclusion trước khi cross-check.

Dùng Steampipe khi nhiệm vụ cụ thể là “query cloud/SaaS inventory bằng SQL trong account lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng. Với Steampipe, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Khi lưu kết quả từ Steampipe, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “cloud-control-plane”: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng.
2. Dùng Steampipe để trả lời đúng một câu hỏi thuộc nhiệm vụ “query cloud/SaaS inventory bằng SQL trong account lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Steampipe làm bằng chứng cuối.

Cross-check: Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Cloud & IAM, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Steampipe thành conclusion trước khi cross-check.

Dùng CloudQuery khi nhiệm vụ cụ thể là “đồng bộ cloud asset metadata vào dataset để audit và inventory” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng. Với CloudQuery, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Khi lưu kết quả từ CloudQuery, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “cloud-control-plane”: Cloud sandbox/project lab, identity test, resource scope, policy/config snapshot và account/region/project identifier rõ ràng.
2. Dùng CloudQuery để trả lời đúng một câu hỏi thuộc nhiệm vụ “đồng bộ cloud asset metadata vào dataset để audit và inventory”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Resource inventory, IAM/policy/config finding, principal-action-resource relation hoặc audit metadata. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của CloudQuery làm bằng chứng cuối.

Cross-check: Dùng provider CLI/API hoặc policy simulator/read-only query thứ hai để xác nhận effective access và loại finding chỉ dựa benchmark label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Cloud & IAM, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output CloudQuery thành conclusion trước khi cross-check.

Dùng Docker CLI khi nhiệm vụ cụ thể là “inspect image/container/network/volume trong môi trường local lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết. Với Docker CLI, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Khi lưu kết quả từ Docker CLI, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “container-cluster-state”: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết.
2. Dùng Docker CLI để trả lời đúng một câu hỏi thuộc nhiệm vụ “inspect image/container/network/volume trong môi trường local lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Docker CLI làm bằng chứng cuối.

Cross-check: So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Containers & Kubernetes, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Docker CLI thành conclusion trước khi cross-check.

Dùng Podman khi nhiệm vụ cụ thể là “chạy và inspect container local, ưu tiên rootless khi phù hợp” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết. Với Podman, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Khi lưu kết quả từ Podman, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “container-cluster-state”: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết.
2. Dùng Podman để trả lời đúng một câu hỏi thuộc nhiệm vụ “chạy và inspect container local, ưu tiên rootless khi phù hợp”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Podman làm bằng chứng cuối.

Cross-check: So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Containers & Kubernetes, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Podman thành conclusion trước khi cross-check.

Dùng kubectl khi nhiệm vụ cụ thể là “query object/log/RBAC của Kubernetes cluster lab được cấp” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết. Với kubectl, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Khi lưu kết quả từ kubectl, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “container-cluster-state”: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết.
2. Dùng kubectl để trả lời đúng một câu hỏi thuộc nhiệm vụ “query object/log/RBAC của Kubernetes cluster lab được cấp”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của kubectl làm bằng chứng cuối.

Cross-check: So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Containers & Kubernetes, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output kubectl thành conclusion trước khi cross-check.

Dùng Helm khi nhiệm vụ cụ thể là “render/review chart values và manifest trong cluster lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết. Với Helm, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Khi lưu kết quả từ Helm, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “container-cluster-state”: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết.
2. Dùng Helm để trả lời đúng một câu hỏi thuộc nhiệm vụ “render/review chart values và manifest trong cluster lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Helm làm bằng chứng cuối.

Cross-check: So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Containers & Kubernetes, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Helm thành conclusion trước khi cross-check.

Dùng k9s khi nhiệm vụ cụ thể là “TUI quan sát resource/log trong Kubernetes lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết. Với k9s, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Khi lưu kết quả từ k9s, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “container-cluster-state”: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết.
2. Dùng k9s để trả lời đúng một câu hỏi thuộc nhiệm vụ “TUI quan sát resource/log trong Kubernetes lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của k9s làm bằng chứng cuối.

Cross-check: So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Containers & Kubernetes, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output k9s thành conclusion trước khi cross-check.

Dùng kube-bench khi nhiệm vụ cụ thể là “kiểm tra CIS-style Kubernetes configuration trên cluster lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết. Với kube-bench, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Khi lưu kết quả từ kube-bench, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “container-cluster-state”: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết.
2. Dùng kube-bench để trả lời đúng một câu hỏi thuộc nhiệm vụ “kiểm tra CIS-style Kubernetes configuration trên cluster lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của kube-bench làm bằng chứng cuối.

Cross-check: So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Containers & Kubernetes, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output kube-bench thành conclusion trước khi cross-check.

Dùng kube-score khi nhiệm vụ cụ thể là “static review Kubernetes manifest offline trước deploy” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết. Với kube-score, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Khi lưu kết quả từ kube-score, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “container-cluster-state”: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết.
2. Dùng kube-score để trả lời đúng một câu hỏi thuộc nhiệm vụ “static review Kubernetes manifest offline trước deploy”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của kube-score làm bằng chứng cuối.

Cross-check: So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Containers & Kubernetes, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output kube-score thành conclusion trước khi cross-check.

Dùng Falco khi nhiệm vụ cụ thể là “runtime detection cho container/Kubernetes lab dựa system-call events” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết. Với Falco, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Khi lưu kết quả từ Falco, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “container-cluster-state”: Container image/manifest hoặc cluster lab, namespace, service account/RBAC và workload fixture đã biết.
2. Dùng Falco để trả lời đúng một câu hỏi thuộc nhiệm vụ “runtime detection cho container/Kubernetes lab dựa system-call events”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Image/config finding, pod/resource state, RBAC rule, runtime event hoặc manifest diff. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Falco làm bằng chứng cuối.

Cross-check: So static manifest với effective cluster state; với runtime finding kiểm tra pod/container identity và event gốc. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Containers & Kubernetes, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Falco thành conclusion trước khi cross-check.

Dùng JADX khi nhiệm vụ cụ thể là “decompile APK lab để đọc Java/Kotlin và trace client logic” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác. Với JADX, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Khi lưu kết quả từ JADX, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “mobile-static-dynamic”: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác.
2. Dùng JADX để trả lời đúng một câu hỏi thuộc nhiệm vụ “decompile APK lab để đọc Java/Kotlin và trace client logic”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của JADX làm bằng chứng cuối.

Cross-check: Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Mobile, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output JADX thành conclusion trước khi cross-check.

Dùng apktool khi nhiệm vụ cụ thể là “decode Android resources/manifest/smali của APK lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác. Với apktool, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Khi lưu kết quả từ apktool, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “mobile-static-dynamic”: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác.
2. Dùng apktool để trả lời đúng một câu hỏi thuộc nhiệm vụ “decode Android resources/manifest/smali của APK lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của apktool làm bằng chứng cuối.

Cross-check: Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Mobile, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output apktool thành conclusion trước khi cross-check.

Dùng adb khi nhiệm vụ cụ thể là “giao tiếp emulator/device test mà bạn sở hữu hoặc được cấp” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác. Với adb, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Khi lưu kết quả từ adb, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “mobile-static-dynamic”: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác.
2. Dùng adb để trả lời đúng một câu hỏi thuộc nhiệm vụ “giao tiếp emulator/device test mà bạn sở hữu hoặc được cấp”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của adb làm bằng chứng cuối.

Cross-check: Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Mobile, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output adb thành conclusion trước khi cross-check.

Dùng Frida khi nhiệm vụ cụ thể là “dynamic instrumentation trên app lab để quan sát function/runtime state” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác. Với Frida, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Khi lưu kết quả từ Frida, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “mobile-static-dynamic”: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác.
2. Dùng Frida để trả lời đúng một câu hỏi thuộc nhiệm vụ “dynamic instrumentation trên app lab để quan sát function/runtime state”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Frida làm bằng chứng cuối.

Cross-check: Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Mobile, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Frida thành conclusion trước khi cross-check.

Dùng Objection khi nhiệm vụ cụ thể là “workflow mobile assessment trên app lab dựa Frida” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác. Với Objection, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Khi lưu kết quả từ Objection, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “mobile-static-dynamic”: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác.
2. Dùng Objection để trả lời đúng một câu hỏi thuộc nhiệm vụ “workflow mobile assessment trên app lab dựa Frida”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Objection làm bằng chứng cuối.

Cross-check: Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Mobile, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Objection thành conclusion trước khi cross-check.

Dùng MobSF khi nhiệm vụ cụ thể là “static/dynamic analysis app lab và tạo findings để review thủ công” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác. Với MobSF, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Khi lưu kết quả từ MobSF, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “mobile-static-dynamic”: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác.
2. Dùng MobSF để trả lời đúng một câu hỏi thuộc nhiệm vụ “static/dynamic analysis app lab và tạo findings để review thủ công”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của MobSF làm bằng chứng cuối.

Cross-check: Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Mobile, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output MobSF thành conclusion trước khi cross-check.

Dùng libimobiledevice khi nhiệm vụ cụ thể là “giao tiếp iOS device test bằng tool open-source trong lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác. Với libimobiledevice, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Khi lưu kết quả từ libimobiledevice, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “mobile-static-dynamic”: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác.
2. Dùng libimobiledevice để trả lời đúng một câu hỏi thuộc nhiệm vụ “giao tiếp iOS device test bằng tool open-source trong lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của libimobiledevice làm bằng chứng cuối.

Cross-check: Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Mobile, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output libimobiledevice thành conclusion trước khi cross-check.

Dùng r2frida khi nhiệm vụ cụ thể là “kết hợp radare2 và Frida cho dynamic reverse trên app lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác. Với r2frida, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Khi lưu kết quả từ r2frida, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “mobile-static-dynamic”: APK/app lab có hash/version, emulator/device test, manifest/resources và account synthetic; không dùng app/tài khoản người khác.
2. Dùng r2frida để trả lời đúng một câu hỏi thuộc nhiệm vụ “kết hợp radare2 và Frida cho dynamic reverse trên app lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Class/method/resource/manifest/storage/network/runtime evidence có thể gắn với version cụ thể của app. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của r2frida làm bằng chứng cuối.

Cross-check: Cross-check static decompile với runtime/emulator observation hoặc raw manifest/smali; không tin decompiler 100%. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Mobile, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output r2frida thành conclusion trước khi cross-check.

Dùng Volatility 3 khi nhiệm vụ cụ thể là “phân tích memory image offline để tìm process/module/network evidence” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc. Với Volatility 3, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Khi lưu kết quả từ Volatility 3, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “forensic-provenance”: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc.
2. Dùng Volatility 3 để trả lời đúng một câu hỏi thuộc nhiệm vụ “phân tích memory image offline để tìm process/module/network evidence”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Volatility 3 làm bằng chứng cuối.

Cross-check: Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Forensics & DFIR, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Volatility 3 thành conclusion trước khi cross-check.

Dùng Autopsy khi nhiệm vụ cụ thể là “GUI case management và filesystem forensics trên image lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc. Với Autopsy, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Khi lưu kết quả từ Autopsy, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “forensic-provenance”: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc.
2. Dùng Autopsy để trả lời đúng một câu hỏi thuộc nhiệm vụ “GUI case management và filesystem forensics trên image lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Autopsy làm bằng chứng cuối.

Cross-check: Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Forensics & DFIR, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Autopsy thành conclusion trước khi cross-check.

Dùng The Sleuth Kit khi nhiệm vụ cụ thể là “filesystem/disk image analysis bằng command line trên artifact copy” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc. Với The Sleuth Kit, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Khi lưu kết quả từ The Sleuth Kit, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “forensic-provenance”: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc.
2. Dùng The Sleuth Kit để trả lời đúng một câu hỏi thuộc nhiệm vụ “filesystem/disk image analysis bằng command line trên artifact copy”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của The Sleuth Kit làm bằng chứng cuối.

Cross-check: Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Forensics & DFIR, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output The Sleuth Kit thành conclusion trước khi cross-check.

Dùng Plaso log2timeline khi nhiệm vụ cụ thể là “parse nhiều nguồn timestamp thành timeline forensic” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc. Với Plaso log2timeline, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Khi lưu kết quả từ Plaso log2timeline, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “forensic-provenance”: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc.
2. Dùng Plaso log2timeline để trả lời đúng một câu hỏi thuộc nhiệm vụ “parse nhiều nguồn timestamp thành timeline forensic”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Plaso log2timeline làm bằng chứng cuối.

Cross-check: Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Forensics & DFIR, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Plaso log2timeline thành conclusion trước khi cross-check.

Dùng Timesketch khi nhiệm vụ cụ thể là “phân tích và annotate forensic timeline trong investigation lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc. Với Timesketch, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Khi lưu kết quả từ Timesketch, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “forensic-provenance”: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc.
2. Dùng Timesketch để trả lời đúng một câu hỏi thuộc nhiệm vụ “phân tích và annotate forensic timeline trong investigation lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Timesketch làm bằng chứng cuối.

Cross-check: Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Forensics & DFIR, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Timesketch thành conclusion trước khi cross-check.

Dùng ExifTool khi nhiệm vụ cụ thể là “đọc metadata file/image offline và phân biệt metadata với kết luận” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc. Với ExifTool, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Khi lưu kết quả từ ExifTool, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “forensic-provenance”: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc.
2. Dùng ExifTool để trả lời đúng một câu hỏi thuộc nhiệm vụ “đọc metadata file/image offline và phân biệt metadata với kết luận”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của ExifTool làm bằng chứng cuối.

Cross-check: Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Forensics & DFIR, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output ExifTool thành conclusion trước khi cross-check.

Dùng binwalk khi nhiệm vụ cụ thể là “inspect/extract embedded data từ firmware/artifact lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc. Với binwalk, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Khi lưu kết quả từ binwalk, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “forensic-provenance”: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc.
2. Dùng binwalk để trả lời đúng một câu hỏi thuộc nhiệm vụ “inspect/extract embedded data từ firmware/artifact lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của binwalk làm bằng chứng cuối.

Cross-check: Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Forensics & DFIR, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output binwalk thành conclusion trước khi cross-check.

Dùng Foremost khi nhiệm vụ cụ thể là “file carving trên disk image synthetic để học recovery” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc. Với Foremost, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Khi lưu kết quả từ Foremost, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “forensic-provenance”: Disk/memory/log/image artifact copy đã hash, timezone/source notes và case question; luôn giữ bản gốc chỉ đọc.
2. Dùng Foremost để trả lời đúng một câu hỏi thuộc nhiệm vụ “file carving trên disk image synthetic để học recovery”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Timeline, process/file/event metadata, carved artifact hoặc indicator có offset/path/hash/provenance. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Foremost làm bằng chứng cuối.

Cross-check: Hash artifact trước/sau, cross-check một observation bằng parser/tool khác và lưu version của parser. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Forensics & DFIR, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Foremost thành conclusion trước khi cross-check.

Dùng Ghidra khi nhiệm vụ cụ thể là “static reverse engineering framework để đọc binary challenge/local artifact” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy. Với Ghidra, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Khi lưu kết quả từ Ghidra, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “static-dynamic-reverse”: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy.
2. Dùng Ghidra để trả lời đúng một câu hỏi thuộc nhiệm vụ “static reverse engineering framework để đọc binary challenge/local artifact”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Ghidra làm bằng chứng cuối.

Cross-check: Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Reverse Engineering, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Ghidra thành conclusion trước khi cross-check.

Dùng IDA Free khi nhiệm vụ cụ thể là “disassembly/decompiler workflow cho binary local ở mức học tập” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy. Với IDA Free, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Khi lưu kết quả từ IDA Free, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “static-dynamic-reverse”: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy.
2. Dùng IDA Free để trả lời đúng một câu hỏi thuộc nhiệm vụ “disassembly/decompiler workflow cho binary local ở mức học tập”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của IDA Free làm bằng chứng cuối.

Cross-check: Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Reverse Engineering, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output IDA Free thành conclusion trước khi cross-check.

Dùng Binary Ninja khi nhiệm vụ cụ thể là “interactive binary analysis và data-flow exploration trên artifact lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy. Với Binary Ninja, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Khi lưu kết quả từ Binary Ninja, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “static-dynamic-reverse”: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy.
2. Dùng Binary Ninja để trả lời đúng một câu hỏi thuộc nhiệm vụ “interactive binary analysis và data-flow exploration trên artifact lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Binary Ninja làm bằng chứng cuối.

Cross-check: Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Reverse Engineering, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Binary Ninja thành conclusion trước khi cross-check.

Dùng radare2 khi nhiệm vụ cụ thể là “command-line reverse framework cho file/binary CTF local” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy. Với radare2, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Khi lưu kết quả từ radare2, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “static-dynamic-reverse”: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy.
2. Dùng radare2 để trả lời đúng một câu hỏi thuộc nhiệm vụ “command-line reverse framework cho file/binary CTF local”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của radare2 làm bằng chứng cuối.

Cross-check: Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Reverse Engineering, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output radare2 thành conclusion trước khi cross-check.

Dùng Cutter khi nhiệm vụ cụ thể là “GUI dựa radare2/Rizin để học graph và decompile local binary” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy. Với Cutter, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Khi lưu kết quả từ Cutter, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “static-dynamic-reverse”: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy.
2. Dùng Cutter để trả lời đúng một câu hỏi thuộc nhiệm vụ “GUI dựa radare2/Rizin để học graph và decompile local binary”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Cutter làm bằng chứng cuối.

Cross-check: Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Reverse Engineering, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Cutter thành conclusion trước khi cross-check.

Dùng objdump khi nhiệm vụ cụ thể là “đọc ELF sections/disassembly/symbols offline” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy. Với objdump, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Khi lưu kết quả từ objdump, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “static-dynamic-reverse”: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy.
2. Dùng objdump để trả lời đúng một câu hỏi thuộc nhiệm vụ “đọc ELF sections/disassembly/symbols offline”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của objdump làm bằng chứng cuối.

Cross-check: Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Reverse Engineering, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output objdump thành conclusion trước khi cross-check.

Dùng readelf khi nhiệm vụ cụ thể là “inspect ELF headers/sections/program headers một cách chính xác” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy. Với readelf, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Khi lưu kết quả từ readelf, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “static-dynamic-reverse”: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy.
2. Dùng readelf để trả lời đúng một câu hỏi thuộc nhiệm vụ “inspect ELF headers/sections/program headers một cách chính xác”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của readelf làm bằng chứng cuối.

Cross-check: Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Reverse Engineering, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output readelf thành conclusion trước khi cross-check.

Dùng strings khi nhiệm vụ cụ thể là “trích printable strings từ artifact và dùng như clue chứ không phải verdict” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy. Với strings, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Khi lưu kết quả từ strings, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “static-dynamic-reverse”: Binary/JAR challenge local có hash, architecture/file format và known input/output; giữ original copy.
2. Dùng strings để trả lời đúng một câu hỏi thuộc nhiệm vụ “trích printable strings từ artifact và dùng như clue chứ không phải verdict”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Functions/xrefs/strings/control-flow/type annotations hoặc runtime state gắn với offset/address và binary hash. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của strings làm bằng chứng cuối.

Cross-check: Cross-check decompiler với disassembly/runtime input-output; mọi patch chỉ trên challenge copy và phải ghi byte/function đã đổi. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Reverse Engineering, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output strings thành conclusion trước khi cross-check.

Dùng GDB khi nhiệm vụ cụ thể là “debug local CTF binary, registers, memory và crash root cause” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost. Với GDB, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Khi lưu kết quả từ GDB, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “local-crash-debug”: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost.
2. Dùng GDB để trả lời đúng một câu hỏi thuộc nhiệm vụ “debug local CTF binary, registers, memory và crash root cause”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của GDB làm bằng chứng cuối.

Cross-check: Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Pwn & Debugging, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output GDB thành conclusion trước khi cross-check.

Dùng pwndbg khi nhiệm vụ cụ thể là “GDB extension giúp quan sát stack/heap/register trong pwn lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost. Với pwndbg, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Khi lưu kết quả từ pwndbg, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “local-crash-debug”: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost.
2. Dùng pwndbg để trả lời đúng một câu hỏi thuộc nhiệm vụ “GDB extension giúp quan sát stack/heap/register trong pwn lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của pwndbg làm bằng chứng cuối.

Cross-check: Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Pwn & Debugging, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output pwndbg thành conclusion trước khi cross-check.

Dùng GEF khi nhiệm vụ cụ thể là “GDB extension phục vụ exploit-development learning trên local challenge” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost. Với GEF, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Khi lưu kết quả từ GEF, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “local-crash-debug”: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost.
2. Dùng GEF để trả lời đúng một câu hỏi thuộc nhiệm vụ “GDB extension phục vụ exploit-development learning trên local challenge”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của GEF làm bằng chứng cuối.

Cross-check: Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Pwn & Debugging, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output GEF thành conclusion trước khi cross-check.

Dùng pwntools khi nhiệm vụ cụ thể là “viết script tương tác và pack/unpack cho CTF service localhost” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost. Với pwntools, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Khi lưu kết quả từ pwntools, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “local-crash-debug”: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost.
2. Dùng pwntools để trả lời đúng một câu hỏi thuộc nhiệm vụ “viết script tương tác và pack/unpack cho CTF service localhost”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của pwntools làm bằng chứng cuối.

Cross-check: Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Pwn & Debugging, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output pwntools thành conclusion trước khi cross-check.

Dùng checksec khi nhiệm vụ cụ thể là “đọc binary mitigation như NX/PIE/RELRO/canary” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost. Với checksec, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Khi lưu kết quả từ checksec, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “local-crash-debug”: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost.
2. Dùng checksec để trả lời đúng một câu hỏi thuộc nhiệm vụ “đọc binary mitigation như NX/PIE/RELRO/canary”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của checksec làm bằng chứng cuối.

Cross-check: Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Pwn & Debugging, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output checksec thành conclusion trước khi cross-check.

Dùng Ropper khi nhiệm vụ cụ thể là “tìm gadget trong binary challenge local để học ROP reasoning” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost. Với Ropper, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Khi lưu kết quả từ Ropper, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “local-crash-debug”: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost.
2. Dùng Ropper để trả lời đúng một câu hỏi thuộc nhiệm vụ “tìm gadget trong binary challenge local để học ROP reasoning”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Ropper làm bằng chứng cuối.

Cross-check: Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Pwn & Debugging, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Ropper thành conclusion trước khi cross-check.

Dùng ROPgadget khi nhiệm vụ cụ thể là “liệt kê gadget của binary CTF local cho bài học control-flow” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost. Với ROPgadget, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Khi lưu kết quả từ ROPgadget, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “local-crash-debug”: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost.
2. Dùng ROPgadget để trả lời đúng một câu hỏi thuộc nhiệm vụ “liệt kê gadget của binary CTF local cho bài học control-flow”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của ROPgadget làm bằng chứng cuối.

Cross-check: Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Pwn & Debugging, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output ROPgadget thành conclusion trước khi cross-check.

Dùng QEMU user-mode khi nhiệm vụ cụ thể là “chạy binary lab khác architecture trong sandbox/emulation” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost. Với QEMU user-mode, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Khi lưu kết quả từ QEMU user-mode, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “local-crash-debug”: Binary CTF local, exact reproducer, mitigation metadata và debugger/sanitizer; remote-like service chỉ bind localhost.
2. Dùng QEMU user-mode để trả lời đúng một câu hỏi thuộc nhiệm vụ “chạy binary lab khác architecture trong sandbox/emulation”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Crash signal, instruction/register/stack/heap state, minimized input hoặc interaction transcript. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của QEMU user-mode làm bằng chứng cuối.

Cross-check: Reproduce crash nhiều lần, minimize input và phân biệt crash với control-flow primitive bằng debugger evidence. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Pwn & Debugging, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output QEMU user-mode thành conclusion trước khi cross-check.

Dùng OpenSSL khi nhiệm vụ cụ thể là “inspect certificate, hash, key và TLS artifact trong lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết. Với OpenSSL, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Khi lưu kết quả từ OpenSSL, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “offline-bytes-crypto”: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết.
2. Dùng OpenSSL để trả lời đúng một câu hỏi thuộc nhiệm vụ “inspect certificate, hash, key và TLS artifact trong lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của OpenSSL làm bằng chứng cuối.

Cross-check: Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Crypto & File Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output OpenSSL thành conclusion trước khi cross-check.

Dùng CyberChef khi nhiệm vụ cụ thể là “recipe-based transform encoding/hash/file data offline cho CTF/forensics” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết. Với CyberChef, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Khi lưu kết quả từ CyberChef, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “offline-bytes-crypto”: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết.
2. Dùng CyberChef để trả lời đúng một câu hỏi thuộc nhiệm vụ “recipe-based transform encoding/hash/file data offline cho CTF/forensics”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của CyberChef làm bằng chứng cuối.

Cross-check: Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Crypto & File Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output CyberChef thành conclusion trước khi cross-check.

Dùng GnuPG khi nhiệm vụ cụ thể là “học encryption/signature/key handling trên file lab” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết. Với GnuPG, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Khi lưu kết quả từ GnuPG, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “offline-bytes-crypto”: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết.
2. Dùng GnuPG để trả lời đúng một câu hỏi thuộc nhiệm vụ “học encryption/signature/key handling trên file lab”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của GnuPG làm bằng chứng cuối.

Cross-check: Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Crypto & File Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output GnuPG thành conclusion trước khi cross-check.

Dùng age khi nhiệm vụ cụ thể là “file encryption hiện đại cho bài lab về key/recipient model” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết. Với age, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Khi lưu kết quả từ age, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “offline-bytes-crypto”: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết.
2. Dùng age để trả lời đúng một câu hỏi thuộc nhiệm vụ “file encryption hiện đại cho bài lab về key/recipient model”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của age làm bằng chứng cuối.

Cross-check: Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Crypto & File Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output age thành conclusion trước khi cross-check.

Dùng xxd khi nhiệm vụ cụ thể là “hex dump và chuyển byte/text cho artifact offline” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết. Với xxd, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Khi lưu kết quả từ xxd, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “offline-bytes-crypto”: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết.
2. Dùng xxd để trả lời đúng một câu hỏi thuộc nhiệm vụ “hex dump và chuyển byte/text cho artifact offline”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của xxd làm bằng chứng cuối.

Cross-check: Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Crypto & File Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output xxd thành conclusion trước khi cross-check.

Dùng hashdeep khi nhiệm vụ cụ thể là “hash inventory và integrity checking trên thư mục artifact” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết. Với hashdeep, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Khi lưu kết quả từ hashdeep, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “offline-bytes-crypto”: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết.
2. Dùng hashdeep để trả lời đúng một câu hỏi thuộc nhiệm vụ “hash inventory và integrity checking trên thư mục artifact”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của hashdeep làm bằng chứng cuối.

Cross-check: Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Crypto & File Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output hashdeep thành conclusion trước khi cross-check.

Dùng ent khi nhiệm vụ cụ thể là “ước lượng entropy của byte stream/file để triage artifact” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết. Với ent, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Khi lưu kết quả từ ent, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “offline-bytes-crypto”: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết.
2. Dùng ent để trả lời đúng một câu hỏi thuộc nhiệm vụ “ước lượng entropy của byte stream/file để triage artifact”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của ent làm bằng chứng cuối.

Cross-check: Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Crypto & File Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output ent thành conclusion trước khi cross-check.

Dùng base64 CLI khi nhiệm vụ cụ thể là “encode/decode representation trong lab và nhấn mạnh encoding không phải encryption” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết. Với base64 CLI, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Khi lưu kết quả từ base64 CLI, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “offline-bytes-crypto”: File/bytes/ciphertext/hash/certificate synthetic hoặc lab key material với algorithm/format context đã biết.
2. Dùng base64 CLI để trả lời đúng một câu hỏi thuộc nhiệm vụ “encode/decode representation trong lab và nhấn mạnh encoding không phải encryption”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Decoded bytes, hashes, certificate fields, entropy/signature/transform intermediate values có thể tái hiện offline. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của base64 CLI làm bằng chứng cuối.

Cross-check: Dùng test vector hoặc tool thứ hai để xác minh transform; luôn phân biệt encoding, hashing, encryption và signature. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Crypto & File Data, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output base64 CLI thành conclusion trước khi cross-check.

Dùng Maltego khi nhiệm vụ cụ thể là “graph relationship từ nguồn public hoặc dataset synthetic với provenance rõ” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp. Với Maltego, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Khi lưu kết quả từ Maltego, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “public-source-provenance”: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp.
2. Dùng Maltego để trả lời đúng một câu hỏi thuộc nhiệm vụ “graph relationship từ nguồn public hoặc dataset synthetic với provenance rõ”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Maltego làm bằng chứng cuối.

Cross-check: Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm OSINT & Public Research, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Maltego thành conclusion trước khi cross-check.

Dùng SpiderFoot khi nhiệm vụ cụ thể là “OSINT automation trên entity/domain lab hoặc mục tiêu nghiên cứu được phép” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp. Với SpiderFoot, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Khi lưu kết quả từ SpiderFoot, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “public-source-provenance”: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp.
2. Dùng SpiderFoot để trả lời đúng một câu hỏi thuộc nhiệm vụ “OSINT automation trên entity/domain lab hoặc mục tiêu nghiên cứu được phép”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của SpiderFoot làm bằng chứng cuối.

Cross-check: Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm OSINT & Public Research, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output SpiderFoot thành conclusion trước khi cross-check.

Dùng theHarvester khi nhiệm vụ cụ thể là “thu thập public-facing references cho domain lab/authorized scope” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp. Với theHarvester, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Khi lưu kết quả từ theHarvester, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “public-source-provenance”: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp.
2. Dùng theHarvester để trả lời đúng một câu hỏi thuộc nhiệm vụ “thu thập public-facing references cho domain lab/authorized scope”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của theHarvester làm bằng chứng cuối.

Cross-check: Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm OSINT & Public Research, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output theHarvester thành conclusion trước khi cross-check.

Dùng Recon-ng khi nhiệm vụ cụ thể là “framework tổ chức module/data OSINT với workspace riêng” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp. Với Recon-ng, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Khi lưu kết quả từ Recon-ng, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “public-source-provenance”: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp.
2. Dùng Recon-ng để trả lời đúng một câu hỏi thuộc nhiệm vụ “framework tổ chức module/data OSINT với workspace riêng”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Recon-ng làm bằng chứng cuối.

Cross-check: Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm OSINT & Public Research, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Recon-ng thành conclusion trước khi cross-check.

Dùng Sherlock khi nhiệm vụ cụ thể là “kiểm tra username trên public sites trong bài OSINT synthetic có quy tắc rõ” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp. Với Sherlock, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Khi lưu kết quả từ Sherlock, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “public-source-provenance”: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp.
2. Dùng Sherlock để trả lời đúng một câu hỏi thuộc nhiệm vụ “kiểm tra username trên public sites trong bài OSINT synthetic có quy tắc rõ”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Sherlock làm bằng chứng cuối.

Cross-check: Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm OSINT & Public Research, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Sherlock thành conclusion trước khi cross-check.

Dùng Shodan CLI khi nhiệm vụ cụ thể là “query dữ liệu Internet index cho asset của chính mình hoặc nghiên cứu được phép” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp. Với Shodan CLI, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Khi lưu kết quả từ Shodan CLI, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “public-source-provenance”: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp.
2. Dùng Shodan CLI để trả lời đúng một câu hỏi thuộc nhiệm vụ “query dữ liệu Internet index cho asset của chính mình hoặc nghiên cứu được phép”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Shodan CLI làm bằng chứng cuối.

Cross-check: Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm OSINT & Public Research, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Shodan CLI thành conclusion trước khi cross-check.

Dùng Censys CLI khi nhiệm vụ cụ thể là “query certificate/host index để inventory asset authorized/public research” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp. Với Censys CLI, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Khi lưu kết quả từ Censys CLI, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “public-source-provenance”: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp.
2. Dùng Censys CLI để trả lời đúng một câu hỏi thuộc nhiệm vụ “query certificate/host index để inventory asset authorized/public research”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Censys CLI làm bằng chứng cuối.

Cross-check: Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm OSINT & Public Research, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Censys CLI thành conclusion trước khi cross-check.

Dùng RDAP client khi nhiệm vụ cụ thể là “tra cứu registration metadata public theo chuẩn RDAP và giữ timestamp nguồn” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp. Với RDAP client, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Khi lưu kết quả từ RDAP client, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “public-source-provenance”: Nguồn public hoặc dataset synthetic, query/entity rõ ràng, thời điểm tra cứu và mục tiêu nghiên cứu hợp pháp.
2. Dùng RDAP client để trả lời đúng một câu hỏi thuộc nhiệm vụ “tra cứu registration metadata public theo chuẩn RDAP và giữ timestamp nguồn”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Public references, graph/registration/certificate metadata có source URL/provider và timestamp. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của RDAP client làm bằng chứng cuối.

Cross-check: Xác minh claim quan trọng từ nguồn gốc hoặc nguồn thứ hai độc lập; không suy identity chỉ từ username/domain similarity. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm OSINT & Public Research, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output RDAP client thành conclusion trước khi cross-check.

Dùng Sigma khi nhiệm vụ cụ thể là “viết detection rule portable từ event behavior và field schema đã biết” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior. Với Sigma, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Khi lưu kết quả từ Sigma, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “detection-validation”: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior.
2. Dùng Sigma để trả lời đúng một câu hỏi thuộc nhiệm vụ “viết detection rule portable từ event behavior và field schema đã biết”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Sigma làm bằng chứng cuối.

Cross-check: Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Blue Team & Detection, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Sigma thành conclusion trước khi cross-check.

Dùng YARA khi nhiệm vụ cụ thể là “match đặc trưng file/memory trên sample corpus offline và đo false positive” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior. Với YARA, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Khi lưu kết quả từ YARA, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “detection-validation”: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior.
2. Dùng YARA để trả lời đúng một câu hỏi thuộc nhiệm vụ “match đặc trưng file/memory trên sample corpus offline và đo false positive”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của YARA làm bằng chứng cuối.

Cross-check: Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Blue Team & Detection, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output YARA thành conclusion trước khi cross-check.

Dùng Chainsaw khi nhiệm vụ cụ thể là “search/hunt Windows Event Log artifacts offline” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior. Với Chainsaw, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Khi lưu kết quả từ Chainsaw, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “detection-validation”: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior.
2. Dùng Chainsaw để trả lời đúng một câu hỏi thuộc nhiệm vụ “search/hunt Windows Event Log artifacts offline”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Chainsaw làm bằng chứng cuối.

Cross-check: Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Blue Team & Detection, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Chainsaw thành conclusion trước khi cross-check.

Dùng Hayabusa khi nhiệm vụ cụ thể là “timeline/triage Windows event logs offline với rules” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior. Với Hayabusa, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Khi lưu kết quả từ Hayabusa, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “detection-validation”: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior.
2. Dùng Hayabusa để trả lời đúng một câu hỏi thuộc nhiệm vụ “timeline/triage Windows event logs offline với rules”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Hayabusa làm bằng chứng cuối.

Cross-check: Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Blue Team & Detection, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Hayabusa thành conclusion trước khi cross-check.

Dùng Wazuh khi nhiệm vụ cụ thể là “HIDS/SIEM lab để thu telemetry và luyện detection/response” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior. Với Wazuh, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Khi lưu kết quả từ Wazuh, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “detection-validation”: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior.
2. Dùng Wazuh để trả lời đúng một câu hỏi thuộc nhiệm vụ “HIDS/SIEM lab để thu telemetry và luyện detection/response”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Wazuh làm bằng chứng cuối.

Cross-check: Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Blue Team & Detection, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Wazuh thành conclusion trước khi cross-check.

Dùng Splunk khi nhiệm vụ cụ thể là “search/correlate logs trong dataset hoặc SIEM lab được quản trị” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior. Với Splunk, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Khi lưu kết quả từ Splunk, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “detection-validation”: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior.
2. Dùng Splunk để trả lời đúng một câu hỏi thuộc nhiệm vụ “search/correlate logs trong dataset hoặc SIEM lab được quản trị”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Splunk làm bằng chứng cuối.

Cross-check: Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Blue Team & Detection, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Splunk thành conclusion trước khi cross-check.

Dùng Elastic Security khi nhiệm vụ cụ thể là “search/detection trên Elastic lab với event schema có kiểm soát” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior. Với Elastic Security, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Khi lưu kết quả từ Elastic Security, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “detection-validation”: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior.
2. Dùng Elastic Security để trả lời đúng một câu hỏi thuộc nhiệm vụ “search/detection trên Elastic lab với event schema có kiểm soát”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Elastic Security làm bằng chứng cuối.

Cross-check: Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Blue Team & Detection, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Elastic Security thành conclusion trước khi cross-check.

Dùng Security Onion khi nhiệm vụ cụ thể là “network/security monitoring distro cho home lab và PCAP/detection exercises” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior. Với Security Onion, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Khi lưu kết quả từ Security Onion, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “detection-validation”: Log/event corpus lab có known-good/known-bad, rule/query version, field schema và expected detection behavior.
2. Dùng Security Onion để trả lời đúng một câu hỏi thuộc nhiệm vụ “network/security monitoring distro cho home lab và PCAP/detection exercises”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Matched event IDs, TP/FP/FN, timeline/hunt results hoặc rule alerts có raw fields. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Security Onion làm bằng chứng cuối.

Cross-check: Rerun cùng corpus, kiểm tra false positive/negative và trace alert về raw event thay vì tin severity label. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Blue Team & Detection, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Security Onion thành conclusion trước khi cross-check.

Dùng Semgrep khi nhiệm vụ cụ thể là “static pattern/data-flow scanning trên source code bạn sở hữu hoặc lab repo” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể. Với Semgrep, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Khi lưu kết quả từ Semgrep, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “code-dependency-review”: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể.
2. Dùng Semgrep để trả lời đúng một câu hỏi thuộc nhiệm vụ “static pattern/data-flow scanning trên source code bạn sở hữu hoặc lab repo”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Semgrep làm bằng chứng cuối.

Cross-check: Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Code Review & Supply Chain, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Semgrep thành conclusion trước khi cross-check.

Dùng CodeQL khi nhiệm vụ cụ thể là “query semantic code database để research vulnerability trong repo lab/authorized codebase” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể. Với CodeQL, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Khi lưu kết quả từ CodeQL, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “code-dependency-review”: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể.
2. Dùng CodeQL để trả lời đúng một câu hỏi thuộc nhiệm vụ “query semantic code database để research vulnerability trong repo lab/authorized codebase”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của CodeQL làm bằng chứng cuối.

Cross-check: Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Code Review & Supply Chain, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output CodeQL thành conclusion trước khi cross-check.

Dùng Gitleaks khi nhiệm vụ cụ thể là “scan repo/history offline để phát hiện secret pattern cần xác minh” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể. Với Gitleaks, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Khi lưu kết quả từ Gitleaks, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “code-dependency-review”: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể.
2. Dùng Gitleaks để trả lời đúng một câu hỏi thuộc nhiệm vụ “scan repo/history offline để phát hiện secret pattern cần xác minh”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Gitleaks làm bằng chứng cuối.

Cross-check: Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Code Review & Supply Chain, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Gitleaks thành conclusion trước khi cross-check.

Dùng TruffleHog khi nhiệm vụ cụ thể là “secret discovery trong repo/artifact bạn được phép kiểm tra” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể. Với TruffleHog, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Khi lưu kết quả từ TruffleHog, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “code-dependency-review”: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể.
2. Dùng TruffleHog để trả lời đúng một câu hỏi thuộc nhiệm vụ “secret discovery trong repo/artifact bạn được phép kiểm tra”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của TruffleHog làm bằng chứng cuối.

Cross-check: Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Code Review & Supply Chain, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output TruffleHog thành conclusion trước khi cross-check.

Dùng ripgrep khi nhiệm vụ cụ thể là “tìm nhanh source/sink/config strings trong codebase local” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể. Với ripgrep, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Khi lưu kết quả từ ripgrep, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “code-dependency-review”: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể.
2. Dùng ripgrep để trả lời đúng một câu hỏi thuộc nhiệm vụ “tìm nhanh source/sink/config strings trong codebase local”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của ripgrep làm bằng chứng cuối.

Cross-check: Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Code Review & Supply Chain, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output ripgrep thành conclusion trước khi cross-check.

Dùng tree-sitter khi nhiệm vụ cụ thể là “parse syntax tree để tự viết code-analysis helper nhỏ” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể. Với tree-sitter, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Khi lưu kết quả từ tree-sitter, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “code-dependency-review”: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể.
2. Dùng tree-sitter để trả lời đúng một câu hỏi thuộc nhiệm vụ “parse syntax tree để tự viết code-analysis helper nhỏ”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của tree-sitter làm bằng chứng cuối.

Cross-check: Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Code Review & Supply Chain, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output tree-sitter thành conclusion trước khi cross-check.

Dùng Bandit khi nhiệm vụ cụ thể là “static security lint cho Python code lab và review từng finding theo context” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể. Với Bandit, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Khi lưu kết quả từ Bandit, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “code-dependency-review”: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể.
2. Dùng Bandit để trả lời đúng một câu hỏi thuộc nhiệm vụ “static security lint cho Python code lab và review từng finding theo context”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Bandit làm bằng chứng cuối.

Cross-check: Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Code Review & Supply Chain, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Bandit thành conclusion trước khi cross-check.

Dùng npm audit khi nhiệm vụ cụ thể là “đọc dependency advisory cho Node project lab và đánh giá reachability/context” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể. Với npm audit, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Khi lưu kết quả từ npm audit, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “code-dependency-review”: Repo/source/lockfile/SBOM lab hoặc codebase bạn sở hữu, revision/commit cố định và câu hỏi review cụ thể.
2. Dùng npm audit để trả lời đúng một câu hỏi thuộc nhiệm vụ “đọc dependency advisory cho Node project lab và đánh giá reachability/context”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Candidate source/sink, advisory/dependency/secret pattern hoặc code path với file/line/commit context. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của npm audit làm bằng chứng cuối.

Cross-check: Đọc code path/reachability và lockfile thực tế; candidate scanner không được gọi là exploitable nếu chưa có manual validation. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Code Review & Supply Chain, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output npm audit thành conclusion trước khi cross-check.

Dùng Dradis khi nhiệm vụ cụ thể là “tổ chức evidence/finding/report trong pentest engagement hợp pháp” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ. Với Dradis, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Khi lưu kết quả từ Dradis, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “evidence-reporting”: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ.
2. Dùng Dradis để trả lời đúng một câu hỏi thuộc nhiệm vụ “tổ chức evidence/finding/report trong pentest engagement hợp pháp”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Dradis làm bằng chứng cuối.

Cross-check: Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Report & Workflow, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Dradis thành conclusion trước khi cross-check.

Dùng Faraday khi nhiệm vụ cụ thể là “collaboration/workspace cho finding và asset trong security assessment” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ. Với Faraday, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Khi lưu kết quả từ Faraday, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “evidence-reporting”: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ.
2. Dùng Faraday để trả lời đúng một câu hỏi thuộc nhiệm vụ “collaboration/workspace cho finding và asset trong security assessment”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Faraday làm bằng chứng cuối.

Cross-check: Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Report & Workflow, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Faraday thành conclusion trước khi cross-check.

Dùng CherryTree khi nhiệm vụ cụ thể là “ghi note dạng cây cho CTF/pentest lab và giữ evidence links” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ. Với CherryTree, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Khi lưu kết quả từ CherryTree, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “evidence-reporting”: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ.
2. Dùng CherryTree để trả lời đúng một câu hỏi thuộc nhiệm vụ “ghi note dạng cây cho CTF/pentest lab và giữ evidence links”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của CherryTree làm bằng chứng cuối.

Cross-check: Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Report & Workflow, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output CherryTree thành conclusion trước khi cross-check.

Dùng Obsidian khi nhiệm vụ cụ thể là “knowledge base Markdown cho research notes và cross-link mental models” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ. Với Obsidian, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Khi lưu kết quả từ Obsidian, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “evidence-reporting”: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ.
2. Dùng Obsidian để trả lời đúng một câu hỏi thuộc nhiệm vụ “knowledge base Markdown cho research notes và cross-link mental models”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Obsidian làm bằng chứng cuối.

Cross-check: Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Report & Workflow, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Obsidian thành conclusion trước khi cross-check.

Dùng Git khi nhiệm vụ cụ thể là “version control cho scripts, notes đã redaction và lab code” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ. Với Git, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Khi lưu kết quả từ Git, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “evidence-reporting”: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ.
2. Dùng Git để trả lời đúng một câu hỏi thuộc nhiệm vụ “version control cho scripts, notes đã redaction và lab code”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Git làm bằng chứng cuối.

Cross-check: Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Report & Workflow, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Git thành conclusion trước khi cross-check.

Dùng Markdownlint khi nhiệm vụ cụ thể là “giữ report/write-up Markdown nhất quán và dễ review” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ. Với Markdownlint, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Khi lưu kết quả từ Markdownlint, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “evidence-reporting”: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ.
2. Dùng Markdownlint để trả lời đúng một câu hỏi thuộc nhiệm vụ “giữ report/write-up Markdown nhất quán và dễ review”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Markdownlint làm bằng chứng cuối.

Cross-check: Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Report & Workflow, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Markdownlint thành conclusion trước khi cross-check.

Dùng Pandoc khi nhiệm vụ cụ thể là “chuyển Markdown report thành document formats trong workflow local” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ. Với Pandoc, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Khi lưu kết quả từ Pandoc, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “evidence-reporting”: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ.
2. Dùng Pandoc để trả lời đúng một câu hỏi thuộc nhiệm vụ “chuyển Markdown report thành document formats trong workflow local”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của Pandoc làm bằng chứng cuối.

Cross-check: Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Report & Workflow, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output Pandoc thành conclusion trước khi cross-check.

Dùng CVSS Calculator khi nhiệm vụ cụ thể là “ghi lại metric severity từ facts đã xác minh thay vì chọn điểm theo cảm giác” và input thuộc lab/artifact/authorized scope. Trước khi mở tool, ghi câu hỏi cần trả lời, baseline, giới hạn dữ liệu và stop condition.

Input: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ. Với CVSS Calculator, chỉ nạp phần dữ liệu cần cho câu hỏi đang kiểm chứng.

Output: Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Khi lưu kết quả từ CVSS Calculator, kèm timestamp/version hoặc raw artifact reference nếu có.

1. Chuẩn bị input theo profile “evidence-reporting”: Notes/evidence đã redaction, scope, reproducer, impact facts và remediation/retest result từ lab/engagement hợp lệ.
2. Dùng CVSS Calculator để trả lời đúng một câu hỏi thuộc nhiệm vụ “ghi lại metric severity từ facts đã xác minh thay vì chọn điểm theo cảm giác”; giữ raw output/field và ghi command/query/filter hoặc thao tác đủ để tái hiện.
3. Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Sau khi đối chiếu, ghi FACT/HYPOTHESIS/RESULT và chỉ đưa vào report phần đã xác minh.

Finding/report có cấu trúc, evidence links, severity rationale, version history hoặc document export. Không dùng riêng nhãn “vulnerable”, “suspicious”, “open”, score hoặc màu cảnh báo của CVSS Calculator làm bằng chứng cuối.

Cross-check: Một reviewer khác phải tái hiện được finding từ report; mọi claim impact phải trỏ về evidence và phần chưa biết phải ghi rõ. Nếu hai nguồn mâu thuẫn, giữ cả hai observation và hạ confidence thay vì chọn kết quả thuận mắt.

Với nhóm Report & Workflow, lỗi hay gặp là bỏ qua input context/provenance, chạy phạm vi rộng hơn câu hỏi, hoặc copy output CVSS Calculator thành conclusion trước khi cross-check.