Penetration testing

Red Team Operations: Report structure and content

What to report

The first stage in building a Red Team report is knowing what to put in the report. Three of the most important things to discuss in the report are identified vulnerabilities, actions taken and any identified compliance gaps.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Identified vulnerabilities

Vulnerabilities identified during the Red Team engagement are the most important details to report. Hopefully, the reason that the client hired the Red Team was to learn about the potential vulnerabilities in their network and how to exploit them, and not just to check a box for compliance.

When reporting vulnerabilities, it is important to provide as much detail as possible to the client. Information that should be collected for reporting includes:

• The details of the vulnerability
• The severity of the vulnerability
• How the vulnerability was discovered
• How the vulnerability can be exploited

This information provides the customer with the information that they need to replicate the issue and also to properly prioritize remediation actions.

Actions taken

During a Red Team assessment, it is critical to record all actions taken during the engagement. This includes both digital actions (scanning, exploitation and so on) and attempts to identify and exploit physical vulnerabilities.

The log of actions taken during the assessment should be used to build a timeline of the events performed during the engagement. This timeline is useful to both the client and the Red Team.

The customer benefits from a timeline of actions taken because it is helpful in understanding the narrative of the exercise (i.e., how the Red Team went from no access to identifying and exploiting vulnerabilities) and to help explain any events that may have occurred on the network. Knowledge of the attack timeline can allow the organization’s security team to look back and identify alerts or other events that could have indicated that the organization was under attack.

An attack timeline and comprehensive records can also help to protect the Red Team if something goes wrong. If one of the customer’s systems goes down or something else happens, it is important that the Red Team be able to prove that it wasn’t their fault or caused by “allowable” actions under the terms of the engagement. It is entirely possible that the customer’s network could be undergoing a real attack during an assessment, and they need to be able to differentiate the real attack from the exercise.

Compliance gaps

Many Red Team assessments are performed with the goal of demonstrating compliance with security regulations or standards. While the Red Team assessment shouldn’t be limited to working through a checklist of compliance requirements, it’s valuable to the customer if any vulnerabilities that would render them noncompliant with applicable regulations are clearly indicated.

Report structure

The report is the most visible and lasting connection between the Red Team and the client organization. Since most Red Team assessments are performed without the knowledge of the organization’s security team, the written report and outbrief are the main contact between the Red Team and internal security team. As a result, it’s important that the report contains all of the information that the security team needs to know regarding the assessment.

Executive summary

In many cases, Red Teams are hired by executives to test their organization’s security, and the executives will certainly be footing the bill for the assessment. However, these parties are probably not going to read the entire Red Team report. The executive summary should provide a high-level description of the results of the assessment and provide the executives with some takeaways that they can use in future reports to their stakeholders.

An executive summary should be succinct and contain the following information:

• A high-level narrative of the assessment
• Types and severities of vulnerabilities found
• Recommendations for fixing any identified problems

Most executives are not technical and don’t want to hear all of the gory details of the engagement. The executive summary should be relatively short and answer one question: “What can I do about it?”

Report body

The goal of the report body is to provide the customer with a full understanding of the Red Team operations. At a minimum, this section should describe the assessment methodology and goals, the attack narrative and findings, and recommendations and mitigations. The contents of this section should provide adequate detail to the customer, enabling them to understand the narrative and discovered vulnerabilities without drowning in detail.

Methodology and goals

Describing the assessment methodology and goals is useful for demonstrating that the Red Team performed the assessment that the client desired. The goals of the exercise should have been negotiated before the assessment starts, and the Red Team and client should agree on what are considered acceptable types of attacks. For example, social engineering is sometimes out of the scope of the assessment. Reiterating this information in the beginning of the report ensures that the reader understands the why and the how of the assessment.

Attack narrative and findings

The attack narrative and findings describe the process by which the Red Team identified each vulnerability discovered in the target network. This section is often divided based on the vulnerability discovered.

Providing a narrative that describes how each vulnerability was discovered is useful to the customer for a couple of reasons. First, it helps with understanding how the Red Team found the vulnerability, which is useful for retroactively identifying potential indicators of compromise and for understanding the methodology used.

An attack narrative is also useful when the customer is working to fix the vulnerabilities discovered. In some cases, it may be impossible to perform the “best” mitigation for a potential vulnerability, and the customer may need to disrupt the attack somewhere upstream.

Recommendations and mitigations

Finally, the Red Team should provide recommendations for potential mitigations for each of the discovered vulnerabilities. The nature of these recommendations will vary according to the discovered vulnerability (e.g., ranging from applying a patch to deploying PKI).

While the Red Team should provide recommendations for mitigations, actually performing the fixes is outside the scope of the Red Teams duties. The Red Team should provide the customer with the necessary detail and/or sample code to test any discovered vulnerabilities.

Appendices and attachments

The appendices and attachments section of the Red Team report are where the Red Team should include all of the details of the assessment. This likely will include the following:

• Log files: If the Red Team covered their tracks, they should provide the security team with unadulterated log files
• List of tools runs: The Red Team should tell the customer all actions taken on their network (with timestamps)
• Tool outputs: The results of running different tests, whether or not vulnerabilities were discovered
• Exploit code: Proof of concept code for testing patches for discovered vulnerabilities
• Signed documentation: Copies of any signed agreements between the Red Team and the customer

Conclusion: Writing the report

Reporting isn’t the most entertaining component of a Red Team assessment. However, it is the most valuable stage for the customer. Putting in the effort to create a useful and valuable report is often what makes the difference between being a one-time hire and being invited back for multiple assessments.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

 

Sources

1. 4 Things Every Penetration Test Report Should Have, Rhino Security Labs
2. Sample Penetration Testing Report, Offensive Security
3. Guide to Red Team Operations, Hacking Articles
4. Deliverables, RedTeam Security