HTB CPTS: PoC, Post-Engagement, Reports and Documentation structure

Proof of Concept

Proof of Concept (PoC) or Proof of Principle is a project management term. In project management, it serves as proof that a project is feasible in principle.

• We confirm discovered vulnerabilities.

• We prepare steps that shows the vulnerability to the owner

• However, there is one significant disadvantage that has occurred from time to time. Once the administrators and developers have received such a script from us, it is easy for them to "fight" against our script. They focus on changing the systems so that the script we created no longer works.

• For example, if a user uses the password Password123, the underlying vulnerability is not the password but the password policy. It can mean that there’s a problem in the organization. No strong password policy.

Post-Engagement

• We have Pre-Engagement in the beginning and Post-Engagement at the end.

Cleanup

• After we’re done we need to perform a cleanup.

  • Delete Tools

  • Delete scripts

  • Revert configuration changes

• We should have detailed notes of our activities so it will be easier to cleanup later.

• If there are places where we cannot visit to delete scripts, we need to inform client about those places.

• We should also document the cleanup process.

Documentation and Reporting

• Before ending the process completely we must prepare adequate documentation for all findings that we plan to include in our report.

• We need top include:

  • Command outputs

  • Screenshots

  • List of affected hosts

• We can’t keep any PII (Personal Identifiable Information)

• We can’t keep incriminating info or other sensitive data we came across throughout testing.

Our Report should consist of the following:

• An attack chain (in the event of full internal compromise or external to internal access) detailing steps taken to achieve compromise

• A strong executive summary that a non-technical audience can understand

• Detailed findings specific to the client's environment that include a risk rating, finding impact, remediation recommendations, and high-quality external references related to the issue

• Adequate steps to reproduce each finding so the team responsible for remediation can understand and test the issue while putting fixes in place

• Near, medium, and long-term recommendations specific to the environment

• Appendices which include information such as the target scope, OSINT data (if relevant to the engagement), password cracking analysis (if relevant), discovered ports/services, compromised hosts, compromised accounts, files transferred to client-owned systems, any account creation/system modifications, an Active Directory security analysis (if relevant), relevant scan data/supplementary documentation, and any other information necessary to explain a specific finding or recommendation further

We create a draft report until and later on we modify it by adding answers to client questions.

Report Review Meeting

Here after client receives a Report, we sit and talk about the results of our assessment. There can also be involved other team members of the company.

This is the meeting where there will be questions from the client.

Sometimes clients come with the list of questions about specific findings.

Post-Remediation Testing

Most engagements include post remediation testing as part of the project’s total cost.

• We will need to reaccess the target environment and test each issue to ensure it was appropriately remediated.

• We will issue a post-remediation report such as:

We should not be implementing changes ourselves or even giving precise remediation advice (i.e., for SQL Injection, we may say "sanitize user input" but not give the client a rewritten piece of code). This will help maintain the assessment's integrity and not introduce any potential conflict of interest into the process.

Data Retention

• We should retain evidence for some time after the penetration test in case questions arise about specific findings or to assist with retesting "closed" findings after the client has performed remediation activities.

• Any data retained after the assessment should be stored in a secure location owned and controlled by the firm and encrypted at rest.

• All data should be wiped from tester systems at the conclusion of an assessment.

Close Out

Once we have delivered the final report, assisted the client with questions regarding remediation, and performed post-remediation testing/issued a new report, we can finally close the project.

• Any artifacts leftover from the engagement are stored securely (encrypted)

• The final steps would be invoicing the client and collecting payment for services rendered.

• As we continually grow our technical skillset, we should always look for ways to improve our soft skills and become more well-rounded professional consultants. In the end, the client will usually remember interactions during the assessment, communication, and how they were treated/valued by the firm they engage.

Practice

• All the theories in the world will be of no use to us if we cannot transfer them into practice and apply our knowledge to real-world, hands-on situations.

• Technical skills are only half the battle, however. We also need excellent written and verbal communication skills to be effective penetration testers.

• Have a friend or teammate act as a fictitious customer. Use that time to practice asking your initial scoping questions and defining the pentest you expect to deliver.

• Penetration testing is fun. What some people may find boring, however, is an essential part: thorough documentation and strong reporting skills.

• A client won't be able to do much with a vague two-page report.

• That being said, if our presentation is sloppy and the report is difficult to follow or does not go in-depth on vulnerability reproduction steps and give clear remediation recommendations, or the executive summary is poorly written, our hard work will not be well-received.

• Take notes while learning and while doing labs. These notes will be valuable as we move along in our careers.

• We also need to learn how to write a non-technical documentation for non technical people. We also need to learn how to keep the quality and concise.