Record keeping. Record keeping is not fun. I very much dislike writing everything down, because you know what? When I'm penetration testing I'm in the zone, I've got my music playing. I know exactly what I'm very focused I've got my methodology down I'm following it, don't interrupt me. But you know what? You've gotta write stuff down, you've gotta say, here's exactly what I am doing, here's the methodology that I'm following. It's a necessary evil, unfortunately. Maybe you like writing everything down, or maybe you like copying and pasting and recording and getting out of the groove of pen testing and actually doing the technical work, the reconnaissance, the exploitation. I love doing reconnaissance, because then I'm finding these little things that I can test. And then when I actually find hey, here's a vulnerability and exploit it, its just fun, but you gotta record everything that you're doing. Record keeping allows a tester or administrator to understand what has transpired. If something went wrong how to fix it so it doesn't happen again. This goes back into risks, so if you exploit something and this goes into post exploitation which we're not going to cover in this lesson. Or these few, well, this entire course, we're not going to talk about post-exploitation. Because what I want you to understand about post-exploitation is, you gotta do something with the data that you've found. So if you found risks you have to go out and patch those. You found vulnerabilities, you have to plug them. Record keeping should be produced in all aspects of a pen test. And writing everything down and telling somebody else, here's exactly what I performed. Here's what you don't need to test again, or here's why I failed to produce a good documentation is going to be the best to anybody looking outside your pen test. If you're ever asked to reproduce the documentation, you have it. A lot of times people will blame your penetration test on things that aren't actually your fault. For example, we run vulnerability scans twice a month and those vulnerability scans everybody blames some network outage on. Now sometimes their legitimate and most of the time they're not or don't blame it on the firewall. But a lot of times we're not doing anything at that time, so having the documentation of what is running when helps you say, I didn't cause this outage. So what should be collected in a pen test? You want to collect all your network logs, all your scripts. Make sure your timelines are extremely detailed. What time did you do what, where? And you can do that if you get screenshots of everything, or even record your screen even. The commands used, tools that were used as well, the results, and screen captures as well. So if you record the screen, you can go back afterward and show what you've actually been doing. There are technologies out there that will record your keystrokes for you. Microsoft actually has a built-in tool to show what has been typed. It's a great tool they use and they'll do screenshots, as well. Documenting findings is also an important part of the final document. Your document should include the background of the pen test, the procedure that you used, the risks identified, the general findings, and the recommendations. Recommendations are great for upper management to say, here is what we need to go after. Here's what we need to protect. So if you are an executive watching this, or maybe you're a manager watching this, make sure that you get recommendations from your security department. Or if you've hired a third party pen tester make sure that you get recommendations back. A technical document on the pen test can also be helpful for any system administrators. Now this isn't an executive summary, but this is a technical summary saying here's everything that I tried. What this can do is this can show system administrators especially if it's not the system administrator performing the pen test, they can understand here's what I need to look at for the future. So there is a warning with your documentation. Make sure that you keep your records secure, this means encrypt them. If you write them in Microsoft word, anything from Word 2010 on up uses AES 256 encryption, so if you put a password, if you protect that document with a password, nobody can read that, so Microsoft word is fine. If you want to protect it with other technologies, make sure it's encrypted with at least AES 256 encryption, because an attacker would love to get their hands on an authorized pen test. Because it details exactly what target to aim for. These are like blueprints or instructions on how to break into systems, how to compromise the systems. Pen tests often take time to plan. So if you got all of your documentation, you basically handed an attacker all the information that they need to know on how to attack you. If records are not secured, an attacker can easily just follow your report and complete all the steps, especially the technical report.
