CompTIA PenTest+ Certification: A Simple Guide To Post-Engagement Activities

Topics:
- Important components of written pentest reports
- Analyzing findings in order to make appropriate recommendations
- Exploring post-delivery activities

- The Anatomy of a Pentest Report
- Reporting Audience
- Report Contents
- Storage and Secure Distribution
- Attestations
- Findings, Recommendations, and Analysis
- Recommendations
- Common Themes and Root Causes
- Post-Engagement Activities
- Cleanup
- Client Acceptance
- Lessons Learned
- Retesting and Follow-up

The pentest report is an important artifact for the customer. The data contained therein can allow senior management to make informed risk decisions on how to prioritize and mitigate security deficiencies in their network. The pentest report provides tangible evidence that portrays the security posture of organizational assets and the effectiveness of installed security countermeasures to protect against an applicable attack vector.
Ultimately, the pentester is responsible for everything that goes into the final report. For some, writing the report may not be as fun as testing and exploitation, but the report is equally as important and can help your customer improve their defenses. Vulnerabilities that are not addressed in the report can get overlooked, leaving the customer susceptible to attack. In this guide, we will discuss best practices for writing and handling a pentest report and test data, analyzing findings and making recommendations, and performing post-report delivery activities.

The Anatomy of a Pentest Report
Congratulations! You’ve finished the grueling process of planning a pentest: driving consensus among all stakeholders, doing all of that research and preparation work, and getting all the contracts signed. You’ve spent hours staring at a screen in a mixture of frustration, confusion, disbelief, and maybe even accomplishment. Hopefully, you kept good notes along the way. Now comes the part few pentesters look forward to: the report. The report, however, is arguably one of the most important parts of an engagement. Its contents justify the pentest. A report communicates the results in writing, contains all of the expert analysis, and describes and provides evidence of the activities undertaken to fulfill the terms of the agreement. So, gather all of your notes and the appropriate testing artifacts to support your story. It’s time to analyze the evidence and create a report.
The report format and contents, audience, and security are your next goals for consideration. The report should organize the relevant details according to the type of test and the goals of the engagement. Regulatory requirements, for example, may dictate that the report observes a specific format or contains certain information. Additionally, you need to frame the information you plan to present for consumption by different audiences. Understanding the expectations of each audience avoids miscommunication and improves efficiency of the deliverable. Finally, you’ll need to make sure that you are being security conscious in your own handling of the report and supporting evidence during the delivery process. We’ll discuss each of these concepts in this section.

Reporting Audience
One of the most important considerations a pentester should keep in mind when preparing for delivery is to know your audience. Data consumers need different information in order to fulfill their responsibilities in the process and may have different understandings of security. Let’s talk about a few examples of report consumers and the kinds of information each may need from pentest deliverables.

The C-Suite
Executives need enough information to make business decisions about security strategy and expenditure. It’s fair to assume that most are not going to want the same level of technical detail as stakeholders with direct responsibility for implementation. Instead, it may be more appropriate to provide summary data, which describes the overall impact to the business, strategic analysis of patterns in findings, and metrics that help determine the current state of security.

Use a bottom-line up-front (BLUF) approach with concise language that describes high-level details in clear layperson’s terms. Most reports should include an executive summary that is tailored to this audience. We’ll discuss that further in the next section.

Technical Staff
Technical audiences may include systems administrators, security control owners, and incident response staff, to name a few. These individuals typically require a more comprehensive and in-depth look at the pentest details. In order to take action to prevent or detect attacks, they need enough detail about how the attack works in order to duplicate it to verify when it is successfully mitigated or to understand what mitigations are appropriate for their specific environment. These audiences often use and understand technical language and concepts as part of their expected job responsibilities. Be prepared to have in-depth discussions exploring the internal details of how a tool; exploit; system; or tactic, technique, or procedure (TTP) works when they have questions. Within the report, the attack narrative, findings and analysis, and even appendix data will likely be key areas of interest for this group.

Developers
Developers are also technical staff, but earn a special distinction in our examination of pentest audiences due to the specialized nature of their concern. Developers are responsible for the creation and maintenance of code, but not necessarily with the implementation of systems or networks. While a system administrator might not have the background to understand the internals of a weakness in source code, developers might be less interested in operating system patching or the impact of network segmentation weaknesses. Developers are most frequently engaged in application testing or in findings that surface weaknesses in the overall software development lifecycle process. Therefore, the kind of information that needs to be shared with developers, and the kinds of clarification they may request, often differ from the requirements of other technical audiences.

Third-Party Stakeholders
Third-party stakeholders frequently are those who do business with the customer being tested. Other businesses who rely on the customer for data processing and cyber insurance processors are two examples of possible third-party stakeholders. Unlike with technical staff and business leaders who are responsible for responding to testing results with measures that change the tested organization’s security response, this audience may not need access to the full pentest report. Instead, they are interested in the outcome of testing as part of an audit process, which asserts that the target organization’s security is being tested. This audience may only need to see an attestation letter rather than any part of the report.

Report Contents
Reports can be written in word processing software, such as Microsoft Word, or with custom tools and web interfaces. However, reports will typically follow common best practices. For instance, you will likely want to include the name and contact information of the tester in case there are questions upon delivery. And you may want to include a table of contents (TOC) at the beginning of the report. If you have figures (screenshots) with captions (e.g., Screenshot 1: Success – Privileged level access to application), you can insert a table of figures as well in the TOC. These tables help organize the report and allow the reader to skip to sections they are most interested in. In this section, we will incorporate some of the report writing guidance offered from multiple sources to introduce you to these concepts for the CompTIA PenTest+ exam.
Reporting requirements can vary based on the type of assessment that was conducted. Regulations, industry standards, and organizational requirements can all influence report contents. But most will contain common pentest report components such as an executive summary, a section regarding findings and recommendations, and a section that details scoping and methodology. Before we go into the different report sections, let’s take a moment to talk about what reports will commonly cover.
Since pentest planning documents are not always included with the report, and since report consumers are not always the same as the stakeholders involved in test planning, the report often summarizes some of that information to provide context for those who are reading the report. Reports should include background information, such as the testing schedule, scope, tools, techniques, and methodologies that were utilized, as well as any limitations placed upon testing so that the results can be understood. Similarly, some best practices apply to presentation of evidence and reporting language.
Choose your screenshots and evidence thoughtfully. Don’t include more information than you need to show to prove your result, but be sure you are including enough detail that report consumers can understand what they’re seeing. Make sure the evidence is readable, and annotate your graphics, if necessary. For example, if you took a screenshot of your terminal window to illustrate how you escalated privileges on the customer LDAP server, you really don’t need to have the scroll bar and menu bar included in the screenshot. You might even be able to include only a part of the screen’s contents. You may want to redact or call out specific elements of interest for your audience. Consider if your evidence includes sensitive information (such as password hashes), can you redact or obfuscate portions of the data to protect it, while still showing that you were able to access it? You might highlight field names that show it contains a password or an administrator account, while blocking out the actual passwords. Regardless of your approach, you will need to be clear with your tone and your explanations.
The tone of a pentest deliverable should always be professional and objective. Avoid the use of accusatory language. For example, “Your sysadmins are bad, because they like to use easily guessable passwords” is not a good professional statement. Your job is not to point fingers or gloat about how you obtained the privileges of a domain administrator; your job is to provide the relevant detail to help your customer improve their security. Educate your consumer! Remain formal and impersonal at all times, and communicate penetration testing deliverables such that each technical concept is phrased clearly and with the relevant detail to support the conclusions. Now, let’s talk about the sections of a pentest report.

Note: : Offensive-Security publishes a sample pentest report you can look at to get an idea of what a report might look like if you have not seen one. Keep in mind that reports vary, both in content and presentation: https://www.offensive-security.com/reports/sample-penetration-testing-report.pdf

Executive Summary
The executive summary is your BLUF summary of the report. Typically, this is one to two pages of information that quickly summarizes key details from the report, including brief context about the time frame of testing, the steps taken, the objective of testing, an ultimate summary of the results, and highlights from recommendations and analysis. The executive summary should not cover information that is not discussed in more detail later in the report. Rather, it should contain the minimum necessary high-level detail to convey key points and be able to stand alone from the remainder of the report. Focus on overall goal attainment, systemic issues, and the impact to the business. Avoid including “the kitchen sink.” The executive summary should address suggested remediation roadmaps, visual representations of key metrics, and strategic analysis of the results. This section should avoid jargon as much as possible and present details in clear, concise language that can easily be understood by a nontechnical audience.

Tip: The Penetration Testing Execution Standard (PTES) contains an example executive summary: https://pentest-standard.readthedocs.io/en/latest/reporting.html#the-executive-summary

Scope Details
The scope can be found in the statement of work (SOW), but should also be defined in the pentest report. The report should cover the scope of the network and systems to be tested during the engagement, such as IP addresses, hostnames, application names and application programming interfaces (APIs), etc. Testing boundaries and network segments should be articulated in such a way that answers all of the questions as to what was actually tested during the engagement. Network architecture drawings can be an effective way of describing the boundaries for testing. If any critical systems were included or excluded from the assessment, that information should be provided as well.
The scope details should also include a statement of limitations, if appropriate. A pentest may have certain limitations or restrictions that control the hours when testing can be conducted, bandwidth restrictions, special testing requirements for legacy systems, duration of testing, or other things that could add overhead to the pentest engagement. Imposing time constraints, especially when operating in different time zones, could require the pentester(s) to change their daily routines to accommodate the customer’s restrictions. Anything preventing the pentest team from interacting with legacy parts of the network is good information to include in the report. This level of detail provides a premise to help support the scenarios executed during the engagement and if the engagement simulated a “real-life” cyber-attack.

Methodology and Attack Narrative
This section covers the penetration testing methodology identified in the SOW. This clarifies what attack types were used and what kind of testing was done. Each method can have one or more activities that can be tested to simulate the approach that could be taken by a threat actor to cause harm to the organization. When drafting the pentest report, you should make sure that you address each of the objectives and methods agreed upon for testing and ensure the information you provide is adequate to helping your customer achieve their overall goals for the pentest, regardless of the report format you choose to use.
 

A testing narrative can provide additional context by telling the story of the pentest. Explaining the logical steps between attacks can help defenders determine the priority for which security changes to make in order to break attack chains. It can also help defenders better understand the nature of the weaknesses that enabled the attack. If you don’t accomplish your goal, it can stand as proof of the effort that was made and share positive kudos about defenses. The PCI “Penetration Testing Guidance” document also suggests that the testing narrative document any issues encountered during testing, such as any type of interference that was encountered or observed as a result of active protection systems (e.g., firewalls, intrusion prevention systems, Network Access Controls [NACs], etc.).
Let’s assume that during an internal pentest engagement your goal was to obtain domain administrator access on the client’s network; however, you could only obtain local administrator access on 10 percent of the in-scope targets, given the time allotted for the pentest. Although you didn’t achieve the objective, the techniques used to obtain local administrator access could be noteworthy to the customer, as corrective actions could be applied using your narrative in order to remediate up to the point where you successfully obtained local administrator access. Following are some further examples of methodology and narrative information for different kinds of reports.

The table suggests examples for descriptions of information gathering for network testing.



Table:   Network Information Gathering

Depending on the type of assessment, you may receive architecture diagrams, web service and API descriptions, etc.

The table suggests activities to assist with executing the web application/API information gathering test, including example results that suggest that the activity was conducted.



Table:   Web Application/API Testing

The table shown suggests activities to assist with executing the mobile platform and application information gathering test, including example results.



Table:   Mobile Platform and Application Testing

Social engineering testing may involve initial discovery using OSINT. A narrative might explain that the tester performed Internet searches to identify personnel of interest who are responsible for system management. As an example:

The pentest team used theHarvester tool to collect e-mail addresses from publicly available resources. The scan data from this activity is located

in Appendix A: OSINT. The following notable e-mail addresses were obtained from the scan:
- [email protected]
- [email protected]
- [email protected]
- [email protected]
 

Pentest Narrative: A Shortened Example
This is a shortened example attack narrative. Note that target details are not included in this example in the interest of brevity.

A narrative may refer to additional data stored in appendixes or include specific details or attack diagrams as needed.

E.g. On November 30, the tester launched a spear phishing campaign targeting ten users. The phishing e-mail contained a link to a staged website (https://fakeurl/fakepage) which contained a JavaScript exploit (CVE-2014-6332) that launches a VBScript and PowerShell-based payload. Four users clicked on the malicious website, causing the payload to download and execute a stager. The stager wrote two executables to disk (pwn.exe and pwn2.exe). The executables conducted automated discovery on the systems and created a persistent scheduled task for our HTTPS-based C2 beacon. The exploit successfully completed on two of the four systems, granting access via a remote shell with SYSTEM-level privileges. The tester was then able to extract credentials, including plaintext passwords, from memory.

On system 4286-D, the user workst-admin was logged in. The tester was able to confirm that this account had administrator access to 23 other systems in the environment based on domain groups and network systems discovery. The tester was able to use this credential to perform lateral movement via remote execution to the system SRV-269 using WMI to remotely create a scheduled task to download and run the staged C2 beacon using the following command…

Findings and Remediation
This section of the report will contain an ordered list of the findings from the test. These are the results of the testing efforts in technical detail. This is often the longest section of the report outside of appendixes.

Techniques for organizing the findings vary based on the kind of pentest and who is conducting testing. It is generally a best practice to order findings by severity in addition to any other criteria used.

Some other criteria include organizing findings by the environment tested, by testing method, or by finding type. Listing the highest-severity findings first can suggest a priority for remediation and set the most serious issues in front for discussion. If a pentest is scoped to include multiple environments, such as multiple applications, devices, or physical sites, those may be grouped into the same report and the findings organized by the environment. Similarly, some consultancies may scope physical penetration testing with wireless or network testing, but choose to provide the results in a single report. In that case, findings may be ordered by the type of testing that led to the finding. Findings might be separated as tactical findings (system-specific weaknesses that resulted in successful attack) or as strategic findings (issues caused by weaknesses in the broader implementation of controls or other approaches to security).

Metrics and Measures
Relevant metrics will vary depending on the nature and goal of the pentest and on the client’s need. What metrics you include and where you include them will depend on what you want to communicate. Metrics should provide visibility into a problem, provide a common language for understanding a program or report, and enable planning and decision making with measurable information. Generally, there are two kinds of metrics: reporting-level metrics and program-level metrics.
Reporting-level measurements apply to the results of a report within the scope of that report. The number of findings or affected targets, the number of findings by type or severity, the impact score overall, or other goal attainment metrics may all be useful, depending on the objectives of the test. Finding types may be based on strategic observations, such as inconsistencies across system configurations within the environment, misapplication of security best practices for handling of sensitive data, or authentication and authorization issues. Impact scoring might apply to data confidentiality, integrity, or availability of key data types and may be expressed as an overall measurement for the test or by individual findings. Goal attainment measurements might include the number of phishing e-mails attempted vs. the number that were clicked vs. the number that resulted in system compromise for a social engineering engagement, as an example.
Program-level measurements are typically designed to measure security maturity and improvement over time. Time to remediation, number of findings by severity or by impact over time, coverage of security assessments across an environment (for example, percentage of applications tested within a portfolio), or even frequency of testing can be program-level metrics. While the scope of a penetration test will often limit the available metrics to the report level, a report consumer may want the report to contain specific metrics or formats in order to compare to the results of previous engagements or remediation initiatives in order to build those program-level trends and statistics.

Conclusion
The conclusion summarizes the pentest results, including a high-level summary of recommendations that can be used to develop a forward-looking roadmap. This section should succinctly and purposefully address wrap-up for all of the issues you brought up in the report. This section shouldn’t wholly repeat what is in the executive summary. Instead, focus on next steps for the report consumer.

Appendixes
Not all reports have or need an appendix, and some reports may have more than one appendix. The easiest way to think of appendixes is that they contain details that would otherwise affect the readability of the report. If a finding affects 200 hosts, listing each host on the same page as the finding would bury the details of the actual test result under pages of hostnames or IP addresses. Instead, you could list the affected hostnames in an appendix and reference it in the finding.
Appendixes are also where you can put information that may not be explicitly part of the scope or evidence, but may still be useful for the report consumer—either to understand the pentest results or to act on remediation. This might include templates used for social engineering pretexts, port and protocol charts, source code references, supporting data regarding targeting (such as relevant device schematics or lists of compromised assets), indicators of compromise (IOCs) from the test (these are useful for client after-action reviews), or testing logs containing timestamps for follow-up investigations. These will go at the end of the report, after the conclusion, and should be grouped and referenced according to each data type’s purpose (i.e., Appendix A: Compromised User Accounts, Appendix B: Application URIs Tested, Appendix C: HID Reader System Diagram).

Storage and Secure Distribution
Pentest reports and evidence contain a lot of sensitive information. They may even be a roadmap to an organization’s total compromise. Therefore, they should be stored and transmitted securely and kept only as long as necessary to satisfy the terms of the contract. The rules of engagement (RoE) will typically define handling instructions agreed upon with the client.

Secure delivery should use a format and distribution method that all parties have agreed upon during the initial planning phases. For example, the pentest report is often written using some type of word processing software (e.g., Microsoft Word, LibreOffice Writer, etc.), which can later be published and delivered to the customer as a PDF to prevent additional changes once the report is completed. This may then be delivered by encrypting the report and using a secure transport mechanism to deliver it. You could use 7zip (https://www.7-zip.org) to compress and encrypt the report, protecting it using a strong password. Then you might upload the report via a secure file transfer service or a secure e-mail delivery system. The key is to follow the agreement that you and the customer made during planning.

Tip: You should not use the same delivery mechanism for the decryption password as you do the encrypted report. This way, you maximize continuity and reduce the risk of unauthorized disclosure should one path become compromised.

The report should be securely stored to avoid tampering or unauthorized disclosure, but retention timelines may vary. As a best practice, the pentest team (or consultant) may wish to consider storing a single digital copy of the report in an encrypted vault and limit and monitor access to that vault to ensure the confidentiality and integrity of the deliverable. The retention interval will often be determined by the terms of the contract, customer demands, and nature of ongoing engagements. For instance, depending on their risk appetite, the customer may ask the pentest team (or consultant) to retain a digital copy of the report until sometime after delivery has been made. The customer may want to issue a final acceptance before remaining copies are properly disposed of. In another case, pentest teams may need to perform retesting and need to access the details of the previous report in order to retrace their steps.

Note: : Every organization has its own level of risk appetite, which is how much risk the organization is willing to tolerate to achieve its goals. In the case of penetration testing, the organization may apply some tight constraints on how their internal environment is accessed, how sensitive data is being handled, and who is allowed to conduct the testing. These control procedures can help reduce the amount of risk exposure during a pentest, should an attack vector lead to a successful compromise.

Attestations
An attestation is a written statement provided by an independent third party (e.g., a pentesting consultancy) that is designed to give the organization credibility to other external parties, often as a part of an audit process. Since attestation letters are provided outside of the report and do not contain specific findings or vulnerability data, they can be publicly shared with outside parties who share concern about the client’s security but should maybe not have in-depth information about the internal environment. An attestation declares that the independent party has performed security testing against the organization and, based on that testing, has observed that the organization is adequately protected according to best practices and the testing done. Of course, this statement only applies to the testing result and what was observed during testing. What the client does or doesn’t do with the results can affect the actual value of the attestation.

Findings, Recommendations, and Analysis
A finding is something that could be advantageous to a malicious threat actor when attacking the customer’s network. Findings should only include actionable items from the exploitation and post-exploitation activities. In your finding template, include a unique identifier, finding name, severity rating, description with evidence, impact, recommendation, and references.

The finding ID is a unique identifier given to a finding that can be used to track prioritization efforts and set milestones to close open findings post-report delivery. Typically, you would include this with each finding and use it for indexing your report or findings section. These IDs will be used for reference during remediation efforts and possibly during trend analysis across pentest engagements.
Since numbers are harder to remember, findings also typically include a short name for reference. This can be a generic name or a summary that describes the weakness, such as “Default password for Tomcat user account.” It should be distinct enough from other findings to be used as a reference, but don’t try to explain the whole details in the name.
A severity rating allows you to rank findings against one another and aids the report consumer to set priority for remediation efforts. Typically, the determination of severity criteria is mutually agreed upon between the tester and the client at the beginning of the engagement. Pentest organizations and consultancies may publish the criteria for severity as part of the report. This can be done qualitatively or quantitatively. The Penetration Testing Execution Standard (PTES) provides a qualitative example scale to use for information security risk rating.

Some organizations may prefer a more numbers-based approach and look to a formal risk rating methodology in an attempt to objectively standardize scoring efforts. Two objective methodologies include the OWASP Risk Rating Methodology2 and the Common Vulnerability Scoring System (CVSS).

Each finding needs to provide a description that allows the reader to understand what the finding means and should provide supporting evidence (i.e., screenshots, notes, proof-of-concept [PoC] examples, etc.) that explains how the vulnerability was exploited. This way the customer can duplicate the finding as part of remediation validation and evaluate possible fixes. In your writing, try to give the reader enough information to put the finding in context, understand how it works, understand its impact to the business, and hopefully how to prevent it from being successfully exploited in the future.

An example writing outline could use the following questions as a guide:
- When did it take place? In the context of other attacks, where does this finding occur?
- What happened?
- Where did it take place? What systems or targets were involved?
- Why did it happen? Was there a particular weakness that allowed this to work?

The impact section should answer the big question: So what? Why should the report consumer care about this finding? What’s the impact of a successful attack? Has this resulted in unauthorized access or transfer of protected or sensitive information? Did this attack enable compromise of other accounts or assets, or a higher level of privilege on one or more assets? Some of this may be built into the severity rating, but this section allows space for the pentester to elaborate on the justification for scoring.

A pentester’s job doesn’t stop at the identification of weakness; we also have to make meaningful suggestions about how to prevent malicious actors from succeeding in future attacks against the same environment. Recommendations may apply to technical controls, administrative controls, operational controls, or physical controls. This is where a pentester’s understanding of operation comes into play. Making actionable and realistic recommendations is very difficult if you do not understand the realities of running an environment for practical use. We’ll address each of these control types in a moment.

Findings may also include additional references that customers can use to get more information about the problem. These answer questions like “how applicable is this weakness in my environment?” These references can be blog posts that explain the attack, industry references regarding best practices, vulnerability writeups, or even presentations and demos that have been made available online.

Example finding:

This guidance may not apply uniformly to all findings, but it does give you a starting point for how to address the findings and testing narratives. Each finding should explain what you did in order to exploit the weakness and provide enough information that the report consumer can understand the impact of that exploitation. For more examples of common findings, the Common Findings Database is a community-driven project with several examples of findings that pentesters have historically found useful: https://github.com/obscuritylabs/OS-CFDB.

Note: : It is not possible for a pentester to evaluate all vulnerability scan findings. Vulnerability scanners may trigger local privilege escalation findings from an unauthenticated remote scan based purely on a banner version that is inaccurate due to backporting. For a pentester who is limited to an external point of view for testing, it is impossible to validate that. This is a key reason why most companies offer a differentiation between vulnerability assessment services and penetration testing. Penetration testing explores actual impact, not potential impact.

Recommendations
Recommendations do not exist only at the finding level. Overall recommendations may appear in the executive summary and conclusion of the report as well. In each case, pentesters fail when they make recommendations that do not adequately address the security problem, but also when recommendations are not reasonable, attainable, or cost-effective.
Always consider the business use case, and remember that remediation does not need to be perfect. It is not always realistic to eliminate all risk. Findings should help the business understand the risk, and recommendations should give them a way to reduce risk to a level they can accept. A perfect solution that renders a system useless is not reasonable.
Recommendations that are impossible due to resource and system limitations or implementation time frames are equally problematic. Weighing the cost of business against the cost of securing that business can be tricky. In an ideal world, we would be able to fix everything the right way, and with infinite money and infinite resources, we could. Unfortunately, tough decisions will sometimes need to be made. Businesses must weigh the potential cost of being affected against the cost of taking action to fix it. Let’s take a look at a few example recommendations in the context of the four categories of controls we introduced earlier: technical controls, administrative controls, operational controls, and physical controls.

Technical Controls
These recommendations apply to security that is enforced automatically as a result of systems settings or software. Make sure your recommendations fall within the operating parameters for the systems in question. Some systems cannot implement long or complex passwords, for example.

Here are some technical control recommendations and when you might use them:
- System hardening is the process of applying system settings and configurations designed to reduce a system’s vulnerability to attack. This recommendation reduces the system attack surface when you see unnecessary service exposure, guest accounts, and default passwords.
- Sanitizing user-controlled inputs and parameterizing queries can help prevent injection attacks.
- Implementing multifactor or password-less authentication can reduce the risk of exposed login interfaces and weak passwords.
- Password encryption can reduce the impact for systems that are compromised in other ways. If passwords are encrypted with a strong algorithm and with secure implementation of encryption, it makes it more difficult for an attacker to use those credentials for subsequent attacks.
- Application whitelisting may be appropriate in an environment where upload and execution of binaries are particularly easy during the pentest.
- Patch management may be a challenge for the company if you are able to identify many known-exploitable vulnerabilities that should have been patched. However, not all systems can be patched because of stability concerns, and network segmentation is sometimes required.
- Password and key rotation should be recommended if very old passwords or keys are identified in the environment. This poses a risk from any previous data exposure, as well as from former staff.
- Standardizing and automating a process for managing the certificate lifecycle should be recommended when expired or misused certificates are identified during testing.
- Secrets management applies to securing certificates, auth keys, and passwords. This is a solid recommendation when you find passwords stored in plaintext or when you identify keys or certificates in insecure locations during a pentest.
- Network segmentation helps reduce the potential impact of compromise by limiting an attacker’s ability to perform lateral movement and eavesdrop on network traffic.

Administrative Controls
These are policies and procedures that are implemented by human actions as opposed to system settings. This may include governance items like security baseline requirements, requirements for what security controls must be installed, and other terms of how systems should be used. Make these recommendations while keeping in mind that, without enforcement, a policy or a standard provides little to no actual security. These recommendations will often operate hand-in-hand with technical controls for enforcement.

Here are some administrative controls recommendations and when you might use them.
- Role-based access control (RBAC) establishes what a person is allowed to access based on their job role. This can mitigate vertical privilege escalation. Recommendations for RBAC come into play when the principle of least privilege is inconsistently applied across accounts, especially with those sharing similar job roles.
- SDLC security protects the organization against attacks on code they develop or use within the enterprise. This extends to supply chain attacks against code that the organization may use as dependencies and insider threats. This recommendation helps if you find cases where source code is easily modified (and the change goes undetected), if you are able to gain access to continuous integration or continuous delivery (CI/CD) infrastructure during a pentest, or if software dependencies lack appropriate integrity checking.
- Password requirement best practices are policies or standards that determine what the technical controls must implement. While technical controls may exist and be in use, if they are not required to meet a reasonable bar for security, the organization may remain vulnerable to brute-force guessing and dictionary attacks.

Operational Controls
Controls that apply to the behavior of people and are enforced by people are operational controls. Recommendations that apply to operational controls attempt to address weaknesses identified in business processes or user behavior as opposed to weak policies or technical implementations. Enforcement often comes with executive backing and relies on employment consequences for these to provide effective improvements to security.

Here are some examples of operational controls recommendations:
- Job rotation and mandatory vacations ensure redundancy in staff capabilities, as well as provide a check to validate an individual’s scope of access. From a security perspective, this recommendation applies in cases where pentests reveal vulnerability or weakness introduced by an employee’s misuse of resources that has gone undetected by the organization.
- Time-of-day restrictions limit when accounts are operational within the environment or when people are allowed access to facilities. These controls can help defenders detect behavioral anomalies that may indicate that an attacker (or a pentester) is acting within the environment. This may be useful as a recommendation when penetration tests observe clearly aberrant hours of activity that go undetected.
- User training is often recommended in cases where social engineering attacks are successful or where people do not observe security best practices, when technical controls cannot fully prevent the attack’s success. Making users aware of what an attack might look like, giving them a sense of responsibility for the security of the enterprise, and educating them about the appropriate course of action during extranormal events can help secure the organization against some attacks.

Physical Controls
Controls that govern physical access to buildings and assets fall under this category. Door locks, cameras, Faraday cages, badge reader systems, guard posts, and fences are all physical controls. Most of the time recommendations that apply to this category will be issued as a result of a physical penetration test, but the same rules about applicability, cost, and feasibility apply. Acting on many of these recommendations involves cost and effort that are not trivial, and they add very little security if the implementation is easily bypassed.

Here are a few examples of physical controls recommendations and when you might suggest them:
- Access control vestibules, air locks, sally ports, or a “mantrap” is a physical space bounded by sets of interlocking doors. This control can be used to trap an intruder inside that space and forbid ingress or egress depending on the access failure. This recommendation may be useful for protecting an area with a higher security need, as it can trap an intruder for further action and protect human and computing assets from harm or theft, and you can require multiple mechanisms of authentication (one for each door) to increase the bar for entry. However, these are typically fairly expensive, and the costs should definitely be weighed against the recommendations.
- Biometric controls involve using personally identifying characteristics, such as an eye scan, handprint, fingerprint, or voiceprint, to increase the difficulty for an attacker to obtain unauthorized access. This is often recommended to bolster existing access control mechanisms.
- Video surveillance recommendations may involve adding or improving camera surveillance of access points. This may be a pertinent recommendation when camera surveillance is not existent, if camera placement is inadequate, or if video quality is insufficient to stand against a physical pentest attempt. However, this recommendation only applies when the surveillance is actively maintained, reviewed, or monitored and responded to.

Common Themes and Root Causes
We’ve talked about recommendations, but your job is not only to identify the finding and propose a recommendation for remediation. Pentesters bring value through expert analysis of the findings. Don’t only think about the tactical fix for the single thing you find. Look for the root cause wherever possible. Not clear about what this means? Let’s say that you found several instances of XSS vulnerabilities and multiple opportunities for successful SQL injection during pentesting. You have findings for each of these, and each has recommendations to sanitize user-controlled input or parameterize queries. But why is this happening so often?
Common themes within your findings may speak to a higher root cause. Findings in a pentest report may sometimes be the direct result of vulnerabilities, implementation weaknesses, development practices, or policy implementations that cause a cascade of findings. Identify those root causes and tailor your advice accordingly. In this case, development practices might be missing oversight to detect these kinds of problems before code is promoted to production (best practices), developers may be reusing insecure code for forms or other user input during development (vulnerabilities), or they may not have the education to realize when additional security measures are required when they code.
In some cases, multiple findings could be resolved by the same actions, and that will need to be reflected in your overall recommendations. So, when you put all of those findings in the report, you should recognize through analysis there’s a common theme. You will need to raise awareness that there is an overall strategic weakness causing security problems in the environment, and you may also need to explain in an executive summary: these findings could all be addressed by socializing security among users, performing better policy enforcement, and maybe even by providing password vaults.

Note: : A top-down management approach is a statement of influence from senior management that dictates goals, objectives, or how something will be done regarding a project or task, then disseminating that vision to lower levels of authority to put a successful plan into action.
Vulnerabilities can be introduced by missing patches, improper handling of user-controlled inputs in applications, and common system misconfigurations, among others.

Here are some examples of common themes and root causes you might encounter:
- Inconsistent patching and configuration management
- Insecure code reuse
- Insecure data handling practices
- Weak/improper use of encryption
- Vulnerable application components
- Ineffective or missing network segmentation
- Inadequate privilege segmentation
- Not following the principle of least privilege
- Insufficient monitoring or incident response processes
- Password reuse or account sharing
- Weak authentication and authorization management
- Lack of best practices, such as secure benchmarks and controls (https://www.cisecurity.org/cybersecurity-best-practices/)

Post-Engagement Activities
Reporting and delivery are not the end of a pentester’s responsibilities to a customer. There are a few other things we need to do at the end of an engagement. Cleanup of testing artifacts, gaining client acceptance, examining our lessons learned, initiating follow-up actions or further testing, and final data destruction are all examples of post-engagement activities we should think about.

Cleanup
You should strive not to leave a tested environment in a vulnerable state. Once you’re certain that testing is complete, it’s time to say goodbye to your shells and your loot and remove persistence mechanisms, payloads, or other testing artifacts. Leaving behind a shell or credential so that it can be leveraged by an attacker is a poor business practice. In some cases, you will need to coordinate these activities with your point of contact, as systems administrators may need to reboot targeted hosts in order to clear the contents of memory, even if nothing was written to disk. Or you may no longer have shell access to a system on which you made changes for testing. Testing tools, such as Metasploit, frequently have mechanisms that are designed to clean up after themselves, but they are not perfect. This is why we take detailed notes about what we did for our report.

Tip: A good rule of thumb: Leave it the way you found it.

Client Acceptance
In some cases, the customer may ask questions to better understand the attack path taken by the pentest team or to share the experiences with more of their support staff, who may have been victimized by the pentest or who were not present at all during testing. Either way, you will still need to provide attestation and supporting evidence of the findings. Any artifacts, presentations, etc., created to support the customer debriefing(s) will also be just as sensitive as the reports, so following recommended storage and delivery mechanisms will likely be required. Some of the benefits of meeting face-to-face is customer acceptance of the findings and group discussion of lessons learned. In some cases, the customer may need to ask questions before they understand the true magnitude of the situation. Sometimes having someone in the room who can articulate the methodologies, draw things out on a whiteboard, or answer a bunch of questions will help get the point across as to why or how something is a finding.

Tip: In the exam or in the exam objectives, the terms “client” or “customer” may be used interchangeably. However, they have the same meaning.

Lessons Learned
Taking the time to objectively examine what went well and what maybe did not go so well during planning, execution, and delivery can help improve client satisfaction, future tests, and testing processes. An example would be following up with your client to find out whether recommendations for remediation are achievable, realistic, and effective at preventing future exploitation using the same techniques. Another example would be looking at what you did during and after testing to determine whether your planning and scoping activities collected the right information, or if you had to go back to your point of contact for additional clarification or re-evaluation during testing. The objective of deriving lessons learned is to make necessary changes to how you work to improve efficacy of the pentest process and the quality of the deliverables.

Retesting and Follow-up
With any luck, the customer will ask you to come back for another assessment. This could be to retest closure of the findings after proper mitigation or for another round of penetration testing at a later time. These types of follow-up actions are a good way to keep in touch with the customer and build a good business relationship with them so they keep seeking out your skills. If the customer has requested validation testing when that is not addressed in your current contract or statement of work, this could be a sign of scope creep and could affect the pentest schedule or completion date for the project. However, the new requirement would be a good justification to use for requesting additional time and funding to complete validation testing.

Review
- Writing the report can be a very time-consuming process.
- Developing a report template can help save time in the long run, as most of the content of how testing activities are conducted and evaluated follow similar procedures and should only require minor edits to make the activity or attack vector applicable to the customer’s environment.
- The executive summary outlines the high-level summaries of the testing activities and does not include the details from the pentest.
- The report should include all of the approved attack vectors and testing activities approved in the RoE, regardless of whether the testing activity yielded any useful results during the pentest.
- This detail gives the customer assurance that they have coverage in certain areas and can prioritize remediation efforts toward areas of concern.
- The pentest report documents the journey that was taken to tell a cohesive story of the customer’s environment and how it stands up to security best practices. Be clear when communicating by using the appropriate level of detail for your intended audience, and describe the necessary information for that audience to understand the results of your test. When the report is completed, it is important to follow the procedures documented in the RoE that identify the report handling requirements to ensure secure delivery of the final product. The stronger the relationship you build with the customer, the more likely they are to request your services again in the future.

References
1.: www.pentest-standard.org/index.php/Reporting
2.: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
3.: https://nvd.nist.gov/vuln-metrics/cvss