Cách sử dụng bộ slide

Bản đồ Chương 5

Từ kiểm thử đến giá trị cho khách hàng

5.1. Understanding Note-Taking

• Ôn lại các deliverable của một penetration testing engagement.
• Hiểu vì sao ghi chú phải có tính portability.
• Nhận diện cấu trúc tổng quát của tài liệu ghi chép pentest.
• Lựa chọn công cụ ghi chú phù hợp.
• Hiểu vai trò của screenshot và sử dụng công cụ chụp màn hình.

Pentest khó viết kịch bản cố định

Scope phải được xác định rõ

Rules of Engagement và giới hạn

Vì sao phải ghi lại quá trình

Note portability là gì?

Nguyên tắc ghi chú có cấu trúc

• Không ghi chung chung với giả định rằng sau này sẽ nhớ lại.
• Ghi chính xác lệnh đã chạy, dòng code đã sửa và thao tác GUI đã thực hiện.
• Ghi đủ chi tiết để loại bỏ sự mơ hồ.
• Đảm bảo thông tin hỗ trợ một báo cáo kỹ thuật có bằng chứng.
• Người khác phải có khả năng lặp lại quy trình và thu được kết quả tương đương.

Cách tổ chức từ rộng đến sâu

Các trường cho một web finding

Ví dụ XSS — vị trí kiểm thử

Ví dụ XSS — kết quả quan sát

Mẫu ghi chú XSS — phần 1

Testing for Cross-Site Scripting 

Testing Target: 192.168.1.52 
Application:    XSSBlog
Date Started:   31 March 2022

1.  Navigated to the application
    http://192.168.1.52/XSSBlog.html
    Result: Blog page displayed as expected

2.  Entered our standard XSS test data: 
    You will rejoice to hear that no disaster has accompanied the
    commencement of an enterprise which you have regarded with such
    evil forebodings.<script>alert("Your computer is infected!");</script> 
    I arrived here yesterday, and my first task is to assure my dear
    sister of my welfare and increasing confidence in the success of
    my undertaking.

Mẫu ghi chú XSS — phần 2

3.  Clicked Submit to post the blog entry.
    Result: Blog entry appeared to save correctly.

4.  Navigated to read the blog post
    http://192.168.1.52/XSSRead.php
    Result: The blog started to display and then the expected alert popped up.

5.  Test indicated the site is vulnerable to XSS.

PoC payload: <script>alert(‘Your computer is infected!')</script>

Ghi chú không phải báo cáo

Tiêu chí chọn công cụ ghi chú

Sublime Text

CherryTree

• Có sẵn trong Kali.
• Lưu ghi chú trong SQLite database.
• Xuất HTML, PDF, plain text hoặc CherryTree document.
• Có định dạng tích hợp và cấu trúc tree gồm node/subnode.

Cài và chạy Obsidian AppImage

kali@kali:~$ wget https://github.com/obsidianmd/obsidian-releases/releases/download/v0.14.2/Obsidian-0.14.2.AppImage

....
2022-03-31 15:38:53 (1.28 MB/s) - 'Obsidian-0.14.2.AppImage' saved [113102744/113102744]

kali@kali:~$ chmod +x Obsidian-0.14.2.AppImage

kali@kali:~$ ./Obsidian-0.14.2.AppImage

Obsidian Vault

• Vault là một thư mục trên hệ thống.
• Có thể tạo Markdown files và folder bên trong.
• Hỗ trợ live preview, chèn ảnh, code blocks và add-ons.
• Có thể di chuyển Vault sang máy khác rồi mở lại.

Ghi chú Markdown trong Obsidian

Live Preview và xuất PDF

So sánh các công cụ trong tài liệu

Quyết định chọn công cụ

Vai trò của screenshot

Khi nào dùng hình, khi nào dùng chữ?

Thiết kế screenshot theo audience

• Tester có thể hiểu ngay một XSS alert, nhưng developer chưa quen với lỗ hổng có thể không hiểu nguyên nhân.
• Hình cần đủ ngữ cảnh để gắn finding với ứng dụng hoặc khách hàng.
• Chỉ giữ lượng thông tin vừa đủ để chứng minh vấn đề.
• Nếu cần ngữ cảnh sâu hơn, giải thích ở đoạn văn phía trên hoặc dưới hình.

Thành phần của screenshot XSS tốt

Ví dụ screenshot tốt

Các lỗi thường gặp khi chụp

• Ảnh hoặc chữ quá nhỏ, buộc người đọc phải zoom.
• Một ảnh chứa hơn một ý kỹ thuật.
• Nội dung quan trọng nằm lệch bên cạnh hoặc bị che.
• Có cửa sổ, terminal hoặc thông tin không liên quan.
• Caption quá dài và cố thay thế phần giải thích.

Ví dụ screenshot không tốt

Checklist screenshot tốt và xấu

Công cụ chụp màn hình trên Windows

Snipping Tool

• Chọn khu vực bất kỳ trên màn hình.
• Phù hợp để lấy đúng bằng chứng cần thiết.
• Giảm lượng thông tin thừa so với chụp toàn màn hình.

macOS, Linux và Flameshot

5.2. Writing Effective Technical Penetration Testing Reports

• Xác định mục đích của technical report.
• Điều chỉnh nội dung theo đúng nhóm người đọc.
• Xây dựng Executive Summary.
• Ghi nhận các điều kiện ảnh hưởng đến testing environment.
• Tạo Technical Summary.
• Mô tả Technical Findings và Recommendations.
• Biết khi nào sử dụng Appendices, Further Information và References.

Báo cáo là deliverable tạo ra giá trị

Hai câu hỏi trước khi viết

Mục tiêu thật sự của engagement

Báo cáo những phần không có finding

• Trong nhiều trường hợp, chỉ cần nêu rằng không phát hiện lỗ hổng.
• Không nên đưa quá nhiều chi tiết về mọi thử nghiệm thất bại nếu chúng làm nhiễu các finding thực sự.
• Một số khách hàng có thể yêu cầu báo cáo rất chi tiết ngay cả với non-issues.
• Mức chi tiết cuối cùng phụ thuộc audience và kỳ vọng đã thống nhất.

Hiểu bối cảnh kinh doanh

Cùng finding, khác bối cảnh

Vị trí khai thác làm thay đổi mức độ

Hai nhóm audience chính

Tách nội dung theo tầng

Executive Summary dùng để làm gì?

Bốn nhóm dữ kiện mở đầu

Mẫu Pertinent Details

Executive Summary:

- Scope: https://kali.org/login.php
- Timeframe: Jan 3 - 5, 2022
- OWASP/PCI Testing methodology was used
- Social engineering and DoS testing were not in scope
- No testing accounts were given; testing was black box from an external IP address
- All tests were run from 192.168.1.2

Long-form Executive Summary

• Tóm tắt ở mức cao từng giai đoạn của engagement.
• Thiết lập severity, context và worst-case scenario cho các finding quan trọng.
• Không undersell và cũng không oversell vulnerability.
• Giúp khách hàng có mental model chính xác về security posture.

Nhận diện trend và lỗi hệ thống

Nêu cả những điểm khách hàng làm tốt

• Management trả tiền cho engagement, nhưng tester thường làm việc trực tiếp với technical security team.
• Không nên khiến đội kỹ thuật cảm thấy bị hạ thấp hoặc bị quy trách nhiệm cá nhân.
• Ngay cả bài kiểm thử có finding nghiêm trọng cũng thường có khu vực được harden tốt.
• Nêu các điểm tích cực giúp report cân bằng và được tiếp nhận tốt hơn.

Mở đầu: mô tả engagement

"The Client hired OffSec to conduct a penetration test of
their kali.org web application in October of 2025. The test was conducted
from a remote IP between the hours of 9 AM and 5 PM, with no users
provided by the Client."

Nêu các kiểm soát hoạt động hiệu quả

"The application had many forms of hardening in place. First, OffSec was unable to upload malicious files due to the strong filtering
in place. OffSec was also unable to brute force user accounts
because of the robust lockout policy in place. Finally, the strong
password policy made trivial password attacks unlikely to succeed.
This points to a commendable culture of user account protections."

Tránh khẳng định tuyệt đối

• Engagement có giới hạn thời gian và nguồn lực.
• Tester có thể không phát hiện một flaw vẫn tồn tại.
• Ngôn ngữ phải để ngỏ khả năng chưa quan sát được đầy đủ.

Trình bày finding và trend

"However, there were still areas of concern within the application.
OffSec was able to inject arbitrary JavaScript into the browser of
an unwitting victim that would then be run in the context of that
victim. In conjunction with the username enumeration on the login
field, there seems to be a trend of unsanitized user input compounded
by verbose error messages being returned to the user. This can lead
to some impactful issues, such as password or session stealing. It is
recommended that all input and error messages that are returned to the
user be sanitized and made generic to prevent this class of issue from
cropping up."

Không tạo trend khi dữ liệu không đủ

• Có thể cần nhiều đoạn để mô tả các nhóm vulnerability khác nhau.
• Dùng đủ số đoạn để minh họa các trend thực sự quan sát được.
• Không gộp các finding không liên quan chỉ để tạo ra một câu chuyện lớn hơn.
• Technical details đầy đủ sẽ được trình bày ở phần sau.

Kết thúc Executive Summary

"These vulnerabilities and their remediations are described in more
detail below. Should any questions arise, OffSec is happy
to provide further advice and remediation help."

Testing Environment Considerations

• Phần đầu của full report nên ghi các vấn đề đã ảnh hưởng đến quá trình kiểm thử.
• Thường đây là một phần ngắn.
• Sai sót hoặc tình huống đặc biệt cần được ghi lại để thể hiện tính minh bạch.
• Không phải mọi chi tiết đều cần đưa vào; báo cáo vẫn phải chuyên nghiệp.

Ba trạng thái kết quả

Mẫu Positive / Neutral / Negative

Mục đích của Technical Summary

• Liệt kê các key finding ở mức kỹ thuật.
• Đưa ra summary và recommendation để security architect hoặc technical lead đọc nhanh.
• Cho biết những việc chính cần được thực hiện.
• Nhóm finding theo khu vực chung, không theo thứ tự thời gian kiểm thử.

Các nhóm finding mẫu

Ví dụ Technical Summary — Patch Management

4. Patch Management

Windows and Ubuntu operating systems that are not up to date were
identified. These are shown to be vulnerable to publicly-available
exploits and could result in malicious execution of code, theft
of sensitive information, or cause denial of services which may
impact the infrastructure. Using outdated applications increases the
possibility of an intruder gaining unauthorized access by exploiting
known vulnerabilities. Patch management ought to be improved and
updates should be applied in conjunction with change management.

Risk heat map

Technical Findings & Recommendations

Giải thích đủ rộng, không quá tải

• Người làm trong cùng công nghệ vẫn có thể không hiểu đầy đủ nuance của vulnerability.
• Không phải lúc nào cũng cần deep dive vào root cause của exploit.
• Nên cung cấp overview về cách exploit xảy ra và attacker có thể làm gì.
• Tốt hơn là giả định audience biết ít hơn và cung cấp đủ thông tin, thay vì bỏ thiếu ngữ cảnh.

Attack narrative khi nào cần?

Cấu trúc một finding dạng bảng

Ví dụ 1 — Account Management

Ví dụ 2 — Anonymous SMB

Ví dụ 3 — Reflected XSS

Technical severity và business risk

Viết phần mô tả vulnerability

Evidence: inline hay Appendix?

Screenshot phải có lời giải thích

• Dùng notes và screenshots để dẫn người đọc qua quá trình đạt kết quả.
• Mỗi screenshot cần một giải thích ngắn về điều nó chứng minh.
• Không dựa vào hình để tự nói lên finding.
• Tác động phải được đặt trong bối cảnh business hoặc application của khách hàng.

Remediation phải khả thi

• Đủ chi tiết để administrator triển khai mà không mơ hồ.
• Rõ ràng, ngắn gọn nhưng đầy đủ.
• Loại bỏ vulnerability theo cách phù hợp với application và khách hàng.
• Không quá tốn kém, không trái văn hóa vận hành và không phá vỡ nhu cầu kinh doanh.

Ba lỗi khi viết remediation

Các bước tái hiện finding

• Chỉ rõ chính xác vị trí application bị ảnh hưởng.
• Mô tả cách trigger vulnerability.
• Ghi đầy đủ từng bước và screenshot hỗ trợ.
• Bao gồm cả điều kiện tester thường xem là hiển nhiên, ví dụ cần chạy với administrative privileges.

Một vulnerability ảnh hưởng nhiều vị trí

• Nếu nhiều khu vực bị ảnh hưởng, tham chiếu từng khu vực.
• Nếu số lượng issue tương tự quá lớn, có thể cung cấp sample.
• Phải ghi rõ sample không phải toàn bộ các vị trí tồn tại lỗi.
• Trong trường hợp lỗi lặp lại rộng, khuyến nghị remediation mang tính hệ thống.

Appendices dùng cho nội dung nào?

Further Information

• Nội dung không bắt buộc cho main write-up nhưng có thể mang lại giá trị.
• Bài viết giải thích vulnerability sâu hơn.
• Standard hoặc guideline để triển khai remediation.
• Các phương pháp khai thác khác có liên quan.

References

• Dùng để cung cấp thêm insight ở các lĩnh vực không trực tiếp thuộc testing.
• Ưu tiên nguồn có thẩm quyền cao nhất.
• Trích dẫn nguồn đúng cách.
• Reference phải hỗ trợ finding hoặc remediation, không làm người đọc phân tâm.

Không có “one tool to rule them all”

• Không có một công cụ ghi chú hoặc report writing phù hợp với mọi người và mọi khách hàng.
• Hãy thử nghiệm nhiều công cụ và chọn workflow phù hợp.
• Công cụ tốt là công cụ giúp viết báo cáo thoải mái, hiệu quả và tuân thủ yêu cầu bảo mật.
• Quy trình nhất quán quan trọng hơn việc chạy theo số lượng tính năng.

Workflow từ ghi chú đến báo cáo

Các sai lầm làm giảm chất lượng report

Checklist tự đánh giá

Tổng kết Chương 5