Writing Pentest Reports | TryHackMe Write-Up • FarrosFR

Here is my article on the walkthrough of a free room: Writing Pentest Reports ↗. Learn how to write professional pentesting reports that communicate risk to business stakeholders. I wrote this in 2025 and hope it is useful for learning about writing pentest reports.

Task 1: Introduction#

This course focuses on writing professional, client-ready penetration testing reports. It teaches you the importance of reporting, how to communicate with different audiences (executives, developers, security engineers), and how to structure a useful report. You’ll learn to present technical findings with business context, write actionable remediation guidance, and maintain a professional tone. By the end, you’ll understand the purpose of pentest reports, how to tailor your language, and how to ensure accuracy and consistency in your reports.

No Answer Needed

Task 2: The Anatomy of a Pentest Report#

This task discusses the importance of tailoring penetration testing reports to different audiences: technical, security, and business stakeholders.

Audience Breakdown:

Technical Stakeholders: The primary audience, usually developers or IT support teams, who need detailed technical guidance on vulnerabilities and remediation steps.
Security Stakeholders: Security teams who prioritize and assess risk but don’t directly remediate vulnerabilities; the report helps them prioritize which issues need immediate attention.
Business Stakeholders: Non-technical individuals, often funding the test, who need to understand the business impact of vulnerabilities and why remediation matters.

Report Sections:

Summary: A high-level overview for business and security stakeholders, focusing on what was tested, what was found, and its business impact.
Vulnerability Write-Ups: Detailed technical explanations for the technical team, including how to replicate and fix vulnerabilities.
Appendices: Supporting details for security stakeholders, such as testing scope, methodology, and artefacts.

The structure of the report ensures that it speaks to all audiences, making it easier for them to take action based on the findings. A well-organized report ensures the findings are not ignored, leading to better prioritization and remediation.

Q1: Which stakeholder should 80% of your report be aimed towards?

Technical

Q2: Which section of the report is for extra information that can sometimes help security stakeholders better understand what coverage was achieved and the next steps that should be followed?

Appendices

Task 3: Report Section 1: Summary#

A penetration testing (pentest) report’s summary is crucial for conveying the assessment’s findings to both technical and non-technical stakeholders. It should address key questions such as:

What was tested? Provide an overview of the systems or applications assessed.
What were the findings? Summarize the vulnerabilities or issues discovered.
What is the impact? Explain the potential consequences of these findings on the business or system.
What are the next steps? Offer high-level remediation recommendations.

This summary should be written in clear, non-technical language to ensure accessibility for all readers. It’s often beneficial to separate the summary into two sections:

Executive Summary: Tailored for business stakeholders, focusing on the strategic impact and necessary actions.
Findings & Recommendations: Directed at security teams, providing detailed insights into vulnerabilities and suggested remediation steps.

By effectively structuring the summary, the report can facilitate informed decision-making and prompt appropriate actions to address identified security issues.

Let us read this instruction below.

This is the best answer to achieve a perfect score of 400/400.

Overview: A black-box penetration test was performed against the TryBankMe platform, TryHackMe’s new online banking system. The test focused on core banking features such as registration, login, and transaction processing, with the aim of identifying security risks before public launch.
[Score: 100]

Results: The application showed good security in most areas tested, including login and access control. However, a race condition was discovered in the transaction feature that could allow users to manipulate balances.
[Score: 100]

Impact: Exploiting the race condition may let attackers trigger multiple overlapping transactions, allowing them to bypass balance checks and generate unauthorised credits.
[Score: 100]

Remediation Direction: Add transaction locking and atomic operations to prevent balance manipulation. Include monitoring for unusual patterns and validate the fix through a focused retest.
[Score: 100]

And then we get the flag to claim the answer. Let’s try.

Q1: What is the value of the flag?

THM{*********.***.********.***********}

Task 4: Report Section 2: Vulnerability Write-Ups#

A vulnerability write-up should explain the vulnerability, where it was found, how it was discovered, and how to remediate it. This section is written primarily for stakeholders who will fix the issues, such as developers and administrators, but can also be reviewed by security analysts or project managers.

A well-structured write-up includes:

Title: A concise heading
Risk Rating: The severity of the vulnerability
Summary: A brief explanation of the issue
Background: Context and why it matters
Technical Details: Evidence of the vulnerability
Impact: What could happen if exploited
Remediation Advice: Clear steps to resolve the issue
References (optional): Links to supporting resources

The report should be tailored to the specific system or environment where the vulnerability was found, ensuring that it is clear and actionable for the client.

We can read the instructions first in the image below.

This is the best answer to achieve a perfect score of 700/700.

Title: Race Condition in Transaction Handling Allows Balance Manipulation
[Score: 100]

Risk Rating: High (CVSS 3.1 Base Score: 8.6) – Exploitation allows unauthorised balance inflation with no authentication bypass required.
[Score: 100]

Summary: A race condition was discovered in the transaction endpoint that enables users to initiate multiple overlapping transfers, resulting in unauthorised increases in account balance.
[Score: 100]

Background: Race conditions occur when a system performs multiple operations simultaneously without proper handling, leading to unexpected outcomes. In web applications, this often affects financial systems where order and timing of requests are critical. Without transaction locking or atomic checks, users can exploit timing to create inconsistent states.
[Score: 100]

Technical Details & Evidence: The issue was confirmed by sending multiple concurrent POST requests to the /transfer endpoint using the same account balance. Using a script, we initiated five identical transfer requests simultaneously. All requests were processed, resulting in a final balance that did not reflect the deduction, effectively duplicating funds.
[Score: 100]

Impact: If left unaddressed, this vulnerability could allow malicious users to create funds out of nothing by exploiting timing gaps in transaction validation. This could lead to direct financial loss, reputational damage, and potential legal implications for failing to safeguard transaction integrity.
[Score: 100]

Remediation Advice: Implement transaction-level locking or atomic operations in the backend to prevent parallel processing of balance-altering actions. Additional safeguards like rate limiting and anomaly detection on rapid or duplicate transactions should also be considered. Validate fixes with targeted retesting.
[Score: 100]

And then you can get the flag for answering the question.

Q1: What is the flag?

THM{****.*********.*******.****.*****}

Task 5: Report Section 3: Appendices#

Assessment Scope#

This appendix outlines the alignment between the actual assessment and the initial scope defined in the Rules of Engagement (RoE). It highlights any deviations, such as areas not tested or changes in testing parameters, providing stakeholders with clarity on the coverage and any potential need for further assessment.

Assessment Artefacts#

This section catalogs any changes or additions made during testing, such as uploaded files or configurations. It serves as an audit trail, ensuring that any remnants from testing are identified and appropriately managed to prevent future security incidents.

Q1: Which appendix will be vital for the blue team to discern if activity is from a pentest or an actual attack?

Assessment Artefacts

Task 6: Styling Guides and Report QA#

Writing a pentest report is about clearly and professionally communicating findings. A well-written report is essential for long-term reference, even after the project team changes. Key points for a strong report include:

Clarity: Use simple, direct language to avoid ambiguity, ensuring your findings are understood by all readers.
Professional Writing: Maintain objectivity and avoid informal language, slang, or emotional tone. Be consistent in terminology and formatting.
Best Practices: Write in past tense, avoid first-person language, mask sensitive data, and use formal phrasing.
Quality Assurance (QA): Review your report for clarity and consistency. Peer review is essential to ensure the report is actionable and professional.

Ultimately, good writing enhances the impact of your findings and ensures they are taken seriously.

To answer the question, we need to read the instructions first in the image below.

First mistake: Credentials should never be shown in clear text, even for test accounts.

Second mistake: ‘Pwned’ is slang and inappropriate in professional reporting.

Third Mistake: ‘Messed around’ is informal and should be replaced with a more professional phrase like ‘conducted timing tests’.

Fourth mistake: The word ‘extensivly’ is a misspelling. It should be ‘extensively’.

And then you can get the flag for answering the question.

Q1: What is the value of the flag?

THM{QA.Makes.Reports.Better}

Task 7: Conclusion#

Publishing a professional pentest report is crucial, as it serves as the lasting evidence of your work. The report should be structured to cater to different audiences, with a clear summary of business risks, detailed vulnerability descriptions, and tailored remediation advice. It’s important to maintain clarity, objectivity, and professionalism throughout the writing process. Quality assurance ensures the report is ready to be delivered. A well-written report transforms technical findings into actionable insights, making a significant impact on improving an organization’s security.

No Answer Needed