195. Destroy Test Data (OBJ 4.2)
In this lesson, we’re going to talk about how you destroy your test data. Now when I’m talking about test data, I’m talking about all the things you’ve collected during this engagement. As you’ve been going through and doing password cracking, as you’ve been going through and doing hash jumps, as you’ve been going through and doing data exfiltration. All of that is considered test data, and at the end of our engagement, we want to purge that data and make sure it’s securely deleted from the systems. This includes the systems we were using as part of our exploitation, as well as our attacking machines, or our own penetration testing internal share drives. Now, when you’re dealing with this data, there’s many different ways to delete it. If you’re using a Linux operating system, you can actually shred that data, which is the process of securely destroying the data by overwriting the storage with new data or a series of random ones and zeros. Inside of the Linux operating system, you can use the shred command to do this for you. Now in Windows, there is not a default shred process that is inside of the operating system. As a penetration tester, you may want to install third party tools on your systems so you’ll be able to securely shred the data afterwards.
If not, another way of doing this is to always save the data to an external hard drive during your engagement, instead of onto your local computer. This way, once you’re done with that engagement, you can fully overwrite that hard drive completely and that will immediately destroy or purge that data. Even better, if you’re using a self-encrypting drive, you can actually do a cryptographic erase of that drive when you’re done with the engagement, and that will make sure that data is totally unrecoverable.
Another area that you need to destroy your test data from is any system you’ve exploited and created as a pivot point, and used that to collect your data before exfiltration. For example, in some penetration tests that I’ve done, we’ve taken control of a workstation and we’ve used that as our collection point inside the network. We would then exfiltrate data from other systems and servers on that network to that particular workstation, which was still located inside the corporate network. Then during the middle of the night, we would then exfiltrate that data over a covert channel back to our headquarters where we can then show that we were successfully able to exfiltrate that data.
Now, at the end of the engagement, we need to go back to that workstation that we used as our data collection point, and either shred the data on that drive, or work with that target organization to actually remove the hard drive from that machine, re-image it by overwriting it multiple times, and then putting a new operating system on for that particular employee. Either way is an acceptable way to do things, but make sure you’re working with your target organization at the end of the engagement to ensure that all the data you’ve collected as part of this test has been properly destroyed, and you don’t have any of it sitting out there that could fall into the wrong hands.
196. Client Acceptance (OBJ 4.2)
In this lesson, we’re going to talk about client acceptance. Now, client acceptance is very important because once you have started this whole engagement it really doesn’t stop until the client agrees that you have finished. This is going to be done by making sure you’ve met all the requirements inside the scope of work of your contract. At the end of your engagement, you want to sit down with your client and do a formal handoff process. This is where you give them your report and you go over the findings in that report to make sure the client understands exactly what you found, how you found it, and what they can do about it. During this formal handoff process, there may be something like a brief to senior stakeholders, or it may just be you meeting with the lead for that particular contract. This does depend on your organization and the target organization that you’re working with. Now, as you’re going through this meeting and presenting the report and your findings to your client, this is a great opportunity to find out if they have any questions, if anything needs to be changed in the report, or are they confident with the conclusions that you’ve reached. At this point, you’re going to be able to gain the client’s acceptance and make sure they’re happy with the services you’ve provided. Part of making sure they’re happy with the services you’ve provided is to ensure that you can get repeat business. As a penetration tester, this isn’t a one and done engagement.
But instead you want to have an ongoing relationship with this particular target. There’s many reasons for this. One is of course you want repeat business because that means another penetration test and another engagement. The second is by going and doing penetration tests with the same client, you already have a lot of the pre-work and reconnaissance done because your previous engagement that you just finished, works as part of your reconnaissance for your next engage as well. The third reason is as you build a relationship between you and that client, you start knowing how to work together and things actually get a lot more efficient and a lot more fun as you start working with that repeat client over and over again, as you both understand the way the other business operates. One final thing to make sure you do with your client is to make sure they understand the value they get from your penetration test. At the end of this engagement, you don’t want them to feel like they’ve been beat up because you’re able to go throughout their entire network and cause all sorts of havoc. Instead you want to remind them that you’re there to help them. You’re there to point out the weaknesses to prevent a bad actor from breaking into their network and having them end up on the evening news. So you want to make sure you show them that there’s this cost benefit analysis going on with doing your penetration test. Yes, it may be expensive. Yes, it may be time consuming. But yes, it is worth it. And you want to make sure that they understand and see the value in the services that you provide and then invite you back for another engagement in the future. Remember, at this point, your goal is to make sure that client was happy and that they accepted that you’ve done everything you were supposed to in your scope of work. So we can mark this engagement as 100% complete.
197. Attestation of Findings (OBJ 4.2)
In this lesson, we’re going to talk about the importance of the attestation of findings. Now, attestation is simply saying that this actually happened. Now, the attestation of findings is essentially a way to prove that the penetration test actually occurred, and it signifies that the findings are actually valid based on the evidence you presented. Now, the attestation of the findings is sometimes required depending on the organization’s reason for conducting a penetration test. If they’re conducting it, just because they as an organization wanted it, they may not require an attestation of findings, but if they’re doing it for a compliance or regulatory reason like making sure they’re compliant with GOBA, HIPAA, Sarbanes-Oxley or PCI DSS, they may require a letter of attestation from your penetration testing firm to show that this is a official record that the penetration test was completed. If you’re asked to provide a letter of attestation or an attestation of your findings, you want to make sure you include a summary of the findings as well as proof that you have conducted the security assessment during a given period of time for that organization. This way the organization can take that letter and show it as proof to a third party to show that they have conducted a security assessment by using your firm for the penetration test. Now, often I get asked, what’s the difference between the attestation of findings and the report that you already delivered? Well, the big difference is that the attestation of findings also includes evidence.
So for example, if you provided a finding that said they were not using multifactor authentication and you’re able to bypass their system by using a standard username and password, now you’re going to provide them evidence to show that that export it actually happened, and they’re not just taking your word for it. This might be a thing where you’re going to sit down with them and go over all the details from the report and pull out your evidence to show them what you did and how you did it. This might include bringing out detailed reports, data, logs, explanations, or even some of your exploit code to show them the risk they have and how you’re able to go about exploiting them. When it comes to attestation, oftentimes you will not leave the evidence with the organization.
For example, if you show them some of your custom show code that you use to be able to exploit their network, you do not have to leave a copy of that with them but you will show it to them during your attestation meeting. This is in contrast to the port that you actually delivered that will show them the finding and the remediation you recommend, but not necessarily the way you exploited that vulnerability. This is the key difference when we’re talking about attestation. Now, normally you’re going to hear people talk about the letter of attestation, like I mentioned earlier. And this is more about the fact that you can prove that the penetration test actually happened and prove that to a third party, who’s interested in the security of the network of the organization you just targeted. But that is really going to depend on the target organization that you’re doing the penetration test for and why they hired you to conduct a penetration test in the first place.
