Documentation & Reporting.md
1 2 You should include an overview section in your report that shows the type of work performed, who performed it, source IP used in testing, testing period and any special considerations 3 4 You should state that any vulnerabilities that is found after the testing period will not be found and reported 5 6 You should document all the activity that you did, such as [[IP|IPs]], tools used, vulnerability targetted 7 8 You can refer to these sample [report](https://mega.nz/file/LgdElBrI#ryjL9J9ThR7pRRXI0UucU4X1_ML2jtzD2kd7wtPU7Q0) for internet penetration testing 9 10 It is also important to keep notes on any findings and important logs that are used in the attack. 11 12 It is suggested to create a good file structure to ensure the notes are easily found and understood 13 14 A sample dir structure for note-taking 15 ```dirtree 16 - /Admin 17 - /Deliverables 18 - /Evidence 19 - /Findings 20 - /Retest 21 ``` 22 23 ## Note Taking 24 25 There are a few things that you should try to include on your notes 26 - `Attack Path` - An outline of the entire path if you gain a foothold during an external penetration test or compromise one or more hosts (or the AD domain) during an internal penetration test. Outline the path as closely as possible using screenshots and command output will make it easier to paste into the report later and only need to worry about formatting. 27 - `Credentials` - A centralized place to keep your compromised credentials and secrets as you go along. 28 - `Findings` - We recommend creating a subfolder for each finding and then writing our narrative and saving it in the folder along with any evidence (screenshots, command output). It is also worth keeping a section in your notetaking tool for recording findings information to help organize them for the report. 29 - `Vulnerability Scan Research` - A section to take notes on things you've researched and tried with your vulnerability scans (so you don't end up redoing work you already did). 30 - `Service Enumeration Research` - A section to take notes on which services you've investigated, failed exploitation attempts, promising vulnerabilities/misconfigurations, etc. 31 - `Web Application Research` - A section to note down interesting web applications found through various methods, such as subdomain brute-forcing. It's always good to perform thorough subdomain enumeration externally, scan for common web ports on internal assessments, and run a tool such as Aquatone or EyeWitness to screenshot all applications. As you review the screenshot report, note down applications of interest, common/default credential pairs you tried, etc. 32 - `AD Enumeration Research` - A section for showing, step-by-step, what Active Directory enumeration you've already performed. Note down any areas of interest you need to run down later in the assessment. 33 - `OSINT` - A section to keep track of interesting information you've collected via OSINT, if applicable to the engagement. 34 - `Administrative Information` - Some people may find it helpful to have a centralized location to store contact information for other project stakeholders like Project Managers (PMs) or client Points of Contact (POCs), unique objectives/flags defined in the Rules of Engagement (RoE), and other items that you find yourself often referencing throughout the project. It can also be used as a running to-do list. As ideas pop up for testing that you need to perform or want to try but don't have time for, be diligent about writing them down here so you can come back to them later. 35 - `Scoping Information` - Here, we can store information about in-scope IP addresses/CIDR ranges, web application URLs, and any credentials for web applications, VPN, or AD provided by the client. It could also include anything else pertinent to the scope of the assessment so we don't have to keep re-opening scope information and ensure that we don't stray from the scope of the assessment. 36 - `Activity Log` - High-level tracking of everything you did during the assessment for possible event correlation. 37 - `Payload Log` - Similar to the activity log, tracking the payloads you're using (and a file hash for anything uploaded and the upload location) in a client environment is critical. More on this later. 38 39 Having a good log of scanning, attack attempts and keep raw tool in your note will be greatly useful when you will be making a report 40 41 ## Report Making 42 43 [Tmux logging](https://github.com/tmux-plugins/tmux-logging) is an excellent for terminal logging. It will show the log in the output and save the output in the file 44 45 If there is no findings, you can show what you had done to the client so that they will know what they are protected against 46 47 You can also use `tee` which is a [[Linux]] command that reads from standard input and writes the output to both standard output (the terminal) and one or more files simultaneously 48 49 List of commands you can use to make a log of all the input and output: 50 - rlwrap 51 - script 52 53 If you had made any changes to an account do include these details: 54 - IP address of the host(s)/hostname(s) where the change was made 55 - Timestamp of the change 56 - Description of the change 57 - Location on the host(s) where the change was made 58 - Name of the application or service that was tampered with 59 - Name of the account (if you created one) and perhaps the password in case you are required to surrender it 60 61 Remember to take screenshot of all the successful exploits as evidence 62 63 **Credential and Personal Identifiable Information(PII) should be redacted in screenshots** 64 65 You should also consider redacting morally questionable things 66 67 *Vulnerability Assessment* is running an automated test and validate the output of the test 68 69 *External Vulnerability Assessment* is performed as an anonymous user from the internet 70 71 *Internal Vulnerability Assessment* is performed as an internal user from within the network. Investigate hosts behind the firewall 72 73 *Penetration Testing* is not only using automated tests but also attacker skills and constraints 74 75 | Types of Pentest | Description | 76 | ---------------- | --------------------------------------------------------------- | 77 | `black box` | Basically no information, other than the name of the company | 78 | `grey box` | Just given in-scope [[IP]] addresses/CIDR network ranges | 79 | `white box` | May be given source codes, credentials, configurations and more | 80 81 `Zero evasion` is not caring about being identified, but finding the most vulnerabilities 82 83 `Hybrid evasive` is starting out evasive and gradually become noisier to know when the defense will pickup 84 85 `Evasive testing` will have the attacker try to remain undetected for as long as possible to find out what they can assess 86 87 *External Pentest* is performed as an anonymous user from the internet 88 89 *Internal Pentest* is performed as an internal user from within the network. Investigate hosts behind the firewall 90 91 *Purple team* assessment will have the attacker simulate and attack and the blue teamer walk through how the internal can detect it 92 93 There are multiple types of reports: 94 **Draft Report:** 95 You send you draft report and organize a meeting with them to allow them to ask questions. They can also add what they might want to see in the final report 96 **Final Report:** 97 Once you have discussed with the client on what they want to see on the report, you will finish you report and submit it to the client 98 **Post Remediation Report:** 99 Once they have fixed their security they might want you to retest your findings, once tested you will send you finding to them again 100 **Attestation Report:** 101 Is for the client to show their stakeholders that they have performed a penetration test. Don't give sensitive info, instead just show how many findings and general comments 102 *Vulnerability notification* is when you find severe vulnerability that is exposed to the internet. This notify the client about the vulnerability before the test is over, they will decide if they want to fix it now or after the test is done. 103 104 You need to include attack chain in your report and show how you use multiple vulnerability together 105 106 When writing an executive summary take these into consideration: 107 - It should be written for someone who is not technical 108 - Don't use typical hacking/programming jargon 109 110 Executive Summary *DOs*: 111 - When talking about metrics, be specific: Don't use a few use 6 112 - It is summary: Don't drag the summary for more than 2 pages 113 - Describe what you got: They don't know what DC is? Explain 114 - How to fix what you found: Tell them what policy should be changed 115 116 Executive Summary *DON'Ts:* 117 - Recommend anyone: Name services like EDR not CrowdStrike 118 - Use acronyms: Don't use acronyms like MitM 119 - Use difficult words: Makes it hard to read the document 120 - Make references: They read executive summary because they don't understand the technicality 121 122 Make a *Summary of Recommendations* section in your report. Give recommendation for short,medium and long-term recommendations 123 124 *Appendices* should be included in every report. Dynamic appendix doesn't have to be in every report. Below are some appendix item that should be included 125 126 | Type of Appendix | Appendix Item | Description | 127 | ---------------- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | 128 | Static | Scope | Shows the scope of the assessment(URL, network range, etc) | 129 | | Methodology | Explain the repeatable process you follow to keep your assessment consistent | 130 | | Severity Ratings | If not directly map to a CVSS score or similar. Articulate your severity methods | 131 | | Biographies | Include the bio of the personnel performing the asessment | 132 | Dynamic | Exploitation Attemps & Payload | To make sure the forensics guy can find the artifacts | 133 | | Compromised Credentials | List down all compromised accounts | 134 | | Configuration Changes | If you made any configuration changes, you should itemize all of them so they can revert it | 135 | | Additional Affected Scope | Long list of affected host | 136 | | Information Gathering | For external pentest. Shows whois data, domain ownership info, etc. Check what you can find [here](https://www.dehashed.com/data) | 137 | | Domain Password Analysis | If you can get the NTDS db and tried cracking it, use [DPAT](https://github.com/clr2of8/DPAT) to show a nice statistic on it | 138 139 When we include our *findings* do include some remediation steps in it and be very detailed so that client's team can replicate what we did. 140 141 When you are writing your *findings* do include: 142 - Description of the finding and what platform(s) the vulnerability affects 143 - Impact if the finding is left unresolved 144 - Affected systems, networks, environments, or applications 145 - Recommendation for how to address the problem 146 - Reference links with additional information about the finding and resolving it 147 - Steps to reproduce the issue and the evidence that you collected 148 149 When including links, it is preferable to link it to your own blog and try to avoid vendors that are trying to sell the client something 150 151 Tools that can be used to speed up report writing: 152 - [[WriteHat]] - [here](https://github.com/blacklanternsecurity/writehat) 153 - [[pwndoc]] - [here](https://github.com/blacklanternsecurity/writehat/blob/master/writehat/settings.py) 154 - [[Ghostwriter]] - [here](https://github.com/GhostManager/Ghostwriter) 155 - [[VECTR]] - [here](https://github.com/SecurityRiskAdvisors/VECTR) 156