The Basics of Hacking and Penetration Testing: Ethical Hacking and Penetration Testing Made Easy, Second Edition (2013)
CHAPTER 8. Wrapping Up the Penetration Test
Information in This Chapter:
Writing the Penetration Testing Report
You Do Not Have to Go Home But You Cannot Stay Here
Where Do I Go From Here?
The Circle of Life
Many people assume that once you have completed each of the four steps outlined in the preceding chapters, the penetration test is over. Many newcomers also assume that immediately following step 4, you can simply call the client to discuss your findings or may be even just send the client a bill for your services. Unfortunately, that is not the case. The reality is that once you wrap up the technical details of a penetration test, there is still one task remaining. After all the reconnaissance, scanning, exploitation, and maintaining access is complete, you need to summarize your findings in the form of a penetration testing report.
It is not uncommon to find extremely gifted hackers and penetration testers who want to completely ignore this final activity. These people have the skill and the ability to compromise nearly any network, but they lack the skills to communicate the vulnerabilities, exploits, and mitigations to the client.
In many respects, writing the penetration testing report is one of the most critical tasks that an ethical hacker performs. It is important to remember that in many cases, the better you do your job as a penetration tester, the less your client will actually notice or “feel” your work. As a result, the final report is often the only tangible evidence that a client will receive from the penetration tester and the penetration testing (PT) process.
The penetration testing report often becomes the face of your organization and reputation. Once the initial contract has been signed providing scope and authorization, the penetration tester often disappears from the target organization. The test itself occurs in a relatively isolated environment. Once the test is completed, it is critical that the penetration tester present his or her findings in a well thought-out, organized, and easy-to-understand manner. Again, it is important to remember that in most cases, the target organization (the company that is paying you) has no concept of what you have been doing or how many hours you have put into the task. As a result, the penetration testing report becomes the principal reflection of your competence. You have a responsibility to the client to present your findings, but you also have an opportunity to showcase your talent and explain how you spent the client’s time and money wisely.
Do not underestimate the power or importance of this phase. In reality, oftentimes your perceived efforts and success will be judged more on your report than your actual success or failure to compromise a network. Ultimately, the ability to write a good penetration testing report will win you business repeatedly.
Writing the Penetration Testing Report
Like every other topic we have discussed, writing a good penetration testing report takes practice. Many penetration testers mistakenly think that they can simply provide the raw output from the tools that they run. This group of people will often collect and neatly organize the various outputs into a single report. They will gather any pertinent information from the reconnaissance phase and include it along with the output from Nmap and Nessus.
Many of the tools we discussed in this book include a reporting engine. For example, Nessus has several prebuilt reports that can be generated based off the scan. Unfortunately, using the prebuilt reports is not enough. Each report must be well laid out and flow as a single document. Combining one style of report from Nessus with a different style of report from Nmap or Metasploit will make the penetration test report appear disjointed and unorganized.
With that being said, it is important to provide the detailed output from each of your tools. Not many of your clients will have the ability to understand the technical output from Nmap or Nessus; however, remember the data do belong to the client and it is important that they have access to the raw data.
We have discussed several examples of what not to do in a penetration testing report; let us examine this issue from a different angle and discuss what should be done.
First and foremost, the penetration testing report needs to be broken into several individual pieces. Taken together, these pieces will form your overall report, but each piece should work as a stand-alone report as well.
At a minimum, a well-rounded and presented penetration testing report should include the following:
1. An executive summary.
2. A walkthrough of how the penetration test was performed to provide an understanding of how you successfully compromised or hacked the system(s).
3. A detailed report.
4. Raw output (when requested) and supporting information.
The executive summary should be a very brief overview of your major findings. This document, or subreport, should not exceed two pages in length and only include the highlights of the penetration test. The executive summary does not provide technical details or terminology. This report needs to be written in the context of board members and nontechnical management so that they can understand your findings and any major concerns you discovered on the network and systems.
If vulnerability and exploits were discovered, the executive summary needs to focus on explaining how these findings impact the business. The executive summary should provide links and references to the detailed report so that interested parties can review the technical nature of the findings. It is important to remember that the executive summary must be very brief and written at a high level. Most executive summaries should be written in such a way that the report writer’s own grandmother would be able to understand what occurred during the penetration test and what the major findings were. It is also a good idea to restate the scope and purpose of the test as well as including overall risk rating for the organization in this portion of the report.
The second part in a well-rounded penetration testing report is the detailed report. This report will include a comprehensive list of your findings as well as the technical details. The audience for this report includes IT managers, security experts, network administrators, and others who possess the skills and knowledge required to read and comprehend its technical nature. In most cases, this report will be used by the technical staff to understand the details of what your test uncovered and how to address or fix these issues.
As with every facet of the penetration test, it is important to be honest and direct with the client. Although it may be tempting to emphasize your great technical savvy and discuss how you owned a particular service, it is much more important to present the facts to your client beginning with the issues that pose the most danger to their networks and systems. Ranking the discovered vulnerabilities can be confusing and daunting for a new penetration tester; luckily most tools like Nessus will provide you with a default ranking system. Always present critical findings first. This makes your penetration test easier to read and allows the client to take action on the most serious findings first (without having to dig through 50 pages of technical output).
Because it is important, it needs to be stated again and it is imperative that you put the needs of the client before your ego. Consider the following example: assume you are conducting a penetration test and are able to fully compromise a server on your target’s network. However, after further investigation and review, you determine that the newly compromised system is of no value. That is, it holds no data, is not connected to any other systems, and cannot be used to pivot further into the network. Later in the penetration test, one of your tools reports a critical vulnerability on a border router. Unfortunately, even after having read the details of the vulnerability and running several tools, you are unable to exploit the weakness and gain access to the system. Even though you are unable to gain access to the border router, you are certain that the system is vulnerable. You also know that because this device is a boarder router, if it is compromised, the entire network will be at risk.
Of course, it should go without saying that in this example both these flaws should be reported. However, the point is that in this case, one flaw clearly presents more danger than the other. In this situation, many newcomers may be tempted to showcase their technical skills and successes by emphasizing the fact that they were able to successfully compromise a server and downplay the importance of the critical vulnerability because the penetration tester was unable to exploit it. Never put yourself or your ego above the security of your clients. Do not overstate the facts; simply report your findings to the best of your ability in an objective manner. Let the client make subjective decisions with the data you provide. Never make up or falsify data in a penetration test. Never reuse “proof-of-concept” screenshots. It can be tempting to take shortcuts by supplying generic, reusable proofs, but it is a dangerous and unethical thing to do.
The idea and use of proof-of-concept screenshots is a powerful tool and should be incorporated into the penetration testing report whenever possible. Anytime you discover a major finding or successfully complete an exploit, you should include a screenshot in the detailed report. This will serve as undeniable evidence and provide the reader with a visualization of your success.
It is also good to remember, especially when you first start conducting penetration tests and that not every PT will result in a “win” or the successful compromise of your target. In most situations, the penetration test is bound by some artificial rules that reduce the reality of the test. These include the demands imposed by the client such as scope, time, and budget as well as the legal and ethical restrictions that help define the boundaries of a penetration test. As you progress in your penetration-testing career, you will undoubtedly encounter situations where your penetration test turns up completely blank, no vulnerabilities, no weaknesses, no useful information gathered, etc. In these situations, you still need to complete the penetration testing report.
Whenever possible, when writing the penetration testing report, you need to include mitigations and suggestions for addressing the issues you discovered. Some tools, like Nessus, will provide suggested mitigations. If your tools do not provide precanned mitigations, then it is important that you locate potential solutions on your own. If you are unsure of where to look for these solutions, most public exploits and vulnerabilities include details or steps that can be taken to address the weakness. Use Google and the Internet to track down specifics of the reported weaknesses. By reviewing the technical details of vulnerability, you will often find potential solutions. These typically include downloading a patch or upgrading to a newer version of the software, although they may discuss other resolutions such as configuration changes or hardware upgrades.
Providing solutions to each of the problems you discover is a vital part of the detailed report. It will also serve to win you repeat business and help to distinguish yourself from other penetration testers.
If you are providing the raw output of your tools as part of the penetration testing report, the findings in the detailed report should include links and references to specific pages in the raw output section. This is important because it will save you time and confused phone calls from your clients who are wondering how you discovered a particular issue. Providing clear references to the raw tool output will allow the client to dig into the details without needing to contact you. In this manner, you should be able to see how the report flows from executive summary to detailed summary to raw output.
When requested, the final portion of the report should be the technical details and raw output from each of the tools. In reality, not every penetration tester will agree that this information needs to be included with the penetration testing report. There is some merit to the arguments against including this detailed information, which includes the fact that this information is often hundreds of pages in length and can be very difficult to read and review. Another common argument often repeated from fellow penetration testers is that providing this level of detail is unnecessary and allows the client to see exactly what tools were run to perform the penetration test.
If you are using custom tools, scripts, or other proprietary code to perform a penetration test, you may not want to reveal this type of information directly to your client. However, in most cases, it is usually safe to provide the direct output of the tools used in the penetration test. This is not to say that you need to provide the detailed commands and switches that were used to run tools like Metasploit, Nmap, or custom code, but rather that you make the output of those commands available. If you are concerned about disclosing the specific commands used to run your tools, you may have to sanitize the raw output to remove those commands and manually delete any other sensitive information you do not want to be disclosed to the readers.
From the view point of a basic penetration test, which typically includes each of the tools we discussed in this book, it would not be out of the question to simply include all the raw output at the end of the report (or to make it available as a separate report). The reason for this is simple—the tools and commands used to invoke each of the tools in a basic penetration test are widely known and available. There is no real point in hiding or attempting to obfuscate this information. Additionally, as mentioned earlier, including the detailed output and making clear references to it in the detailed report will often save you time and phone calls from frustrated clients who do not understand your findings.
Whether you decide to include the raw data as an actual component of the report or you decide to include it as a separate document is entirely up to you. Depending on the sheer size of this report, you may want to simply include it as a secondary or stand-alone report and not attach it directly with the executive summary and the detailed reports.
Another consideration that needs to be given some careful thought is how you will present your report to the client. This is something that should be discussed prior to the delivery of the report. From a purely time-management and resource standpoint, it is often easier to deliver the report as an electronic document. In the case where the client requests a paper copy, you will need to professionally print, bind, and mail the document to the client. Be sure to send the document via certified mail and always request a return receipt so you can verify that the document was properly received.
If you have agreed to deliver the document electronically, you will need to ensure that the penetration testing report is encrypted and remains confidential until it arrives in the client’s hands. Remember a penetration testing report often contains very sensitive information about the organization. You must ensure the information contained in the report remains private. It would be very embarrassing to have a report you created become public because you did not take the basic measures needed to ensure confidentiality.
There are several easy ways of ensuring confidentiality. You can use a tool like 7zip to compress and add a password to the files. A much better way of encrypting a document is to use a tool like TrueCrypt to encrypt the documents. TrueCrypt is an easy-to-use program and can be downloaded for free from http://www.truecrypt.org. Regardless of what type of encryption or protection scheme you use, your client will need to use the same tool to decrypt and view the files. This is an arrangement that should be agreed upon before the penetration test begins. Some of your clients may not understand even the basics of cryptography. As a result, you may need to work with and train them on the proper techniques needed to view your final report.
Each section or individual subreport should be clearly labeled and should begin on a new page. Under the heading of each report, it may be a good idea to emphasize to the reader that the penetration test is only a snapshot in time. The security of networks, computers, systems, and software is dynamic. Threats and vulnerabilities change at lightning speed. As a result, a system that appears completely impenetrable today can be easily compromised tomorrow if a new vulnerability is discovered. As a way of indemnifying yourself against this rapid change, it is important to communicate that the results of the test are accurate as of the day you completed the assessment. Setting realistic client expectations is important. Remember, unless you fill a computer with concrete, drop it in the middle of the ocean, and unplug it from the Internet, there is always a chance that the system can be hacked by some unknown technique or new zero-day flaw.
Finally, take your time to prepare, read, reread, and properly edit your report. It is equally as important to provide a document that is technically accurate as well as one that is free of spelling and grammar issues. Technical penetration testing reports that contain grammar and spelling mistakes will indicate to your client that you perform sloppy work and reflect negatively on you. Remember the penetration testing report is a direct reflection of you and your ability. In many cases, the report is the single output that your client will see from your efforts. You will be judged based on the level of its technical detail and findings as well as its overall presentation and readability.
While you are reviewing your report for mistakes, take some time to closely review the detailed output from your various tools. Remember, many of the tools that we use are written by hackers with a sense of humor. Unfortunately, hacker humor and the professional world do not always mesh. When I first started as penetration tester, a colleague and I found ourselves in an embarrassing situation. One of my favorite tools (Burp Suite) had attempted to log into a particular service several hundred times using the name “Peter Weiner”. As a result, our professional-looking report was filled with examples of a not-so-professional user account belonging to Peter Weiner. It is not easy to go into a boardroom full of professional, suit-wearing executives and discuss your fictitious user named Peter Weiner.
It is worth noting that in this case, the mistake was 100% mine. The guys at PortSwigger clearly discuss how to change this user name in the configuration settings and a more careful inspection of the reports would have caught this before my presentation. Had I properly reviewed the report and findings, I would have had plenty of time to correct it (or at least come up with a good excuse!).
Right or wrong, your reputation as a penetration tester will have a direct correlation to the quality of the reports that you put out. Learning to craft a well-written penetration test is critical for earning repeat customers and earning future business. It is always a good idea to have a sample report in hand. Many prospective clients will ask for a sample report before making a final decision. It is worth noting that a sample report should be just a sample. It should not include any actual data from a real customer. Never give a previous client’s report out as a sample, as this could represent a massive violation of the implied or contractual confidentiality between you and your client.
To wrap up the report-writing phase, it is worth mentioning that most clients will expect you to be available after the report has been delivered. Because of the technical and detailed nature of the penetration testing process and report, you should expect to receive a few questions. Here again, taking time and answering each question should be viewed as an opportunity to impress the client and win future business rather than as an annoyance. Ultimately, good customer service is worth its weight in gold and will often repay you 10-fold. Naturally, your willingness to work with a client and provide additional services has to make business sense as well. You are not required to “overservice” the account and provide endless hours of free support, but rather you need to find a balance between providing exceptional customer service and healthy profits.
You Do Not Have to Go Home but You Cannot Stay Here
Assuming you have read the entire book (congrats by the way!), you are probably wondering “what’s next?” The answer to that question depends entirely on you. First, it is suggested that you practice and master the basic information and techniques presented in this book. Once you are comfortable with the basics, move onto the advanced topics and tools covered in the “Where Do I Go from Here” section of each chapter.
After mastering all the material in this book, you should have a solid understanding of the hacking and penetration testing process. You should feel comfortable enough with the basic information that you are able to take on advanced topics and even specialize.
It is worth noting, however, that there is much more to hacking and penetration testing than just running tools. There are entire communities out there that are built around these topics. You should become active in these communities. Introduce yourself and learn by asking questions and observing. You should give back to these communities whenever possible. Hacking, security, and penetration testing communities are available through various websites, online forums, ICQ, mailing lists, and news groups, and even in person.
Chat rooms are a great place to learn more about security. Chat rooms are usually highly focused on a single topic and, as the name implies, typically involve lots of communication over a wide variety of subtopics pertaining to the overall theme of the room. In many respects, a chat room is like sitting at a bar and listening to the conversations around you. You can participate by asking questions or simply by sitting quietly and reading the conversations of everyone in the room.
If you have never been to a security conference (also known as a “CON”), you owe it to yourself to go. DEFCON is an annual hacker convention held in Las Vegas at the end of each summer. Yes it is a bit of a circus, yes there are more than 11,000 people attending, and yes it is hot in Las Vegas in August. But despite all that, DEFCON remains one of the single, best security communities on earth. In general, the crowds are very pleasant, the Goons (official DEFCON workers) are friendly and helpful, and the community is open and inviting. The price of admission is peanuts compared to some of the other security events, and one more thing—the talks are amazing.
The quality and variety of talks at DEFCON are nothing short of mind boggling. Talks vary each year, but they are sure to include the topics of network hacking, web app security, physical security, hardware hacking, lock picking, and many more. The speakers are not only approachable, more often than not they are willing to take time and talk to you, answering your questions one on one. It is consistently amazing how approachable and helpful CON speakers are. It is natural to be a little nervous when approaching someone at a conference, especially if you have been part of an online community where “newbies” are put down and questions are discouraged; however, if you take the initiative, you will often be pleasantly surprised by the openness of the entire DEFCON community.
Another great conference to look into is DerbyCon. DerbyCon is typically held in Louisville, Kentucky each Fall. Dave Kennedy who helped to organize this book is one of the cofounders of DerbyCon. This is a rocking conference that pulls in some of the biggest names in security and offers a more “intimate” (1000–1500 attendees) experience. You can find all the details at http://www.derbycon.com.
If you cannot make it to the official DEFCON conference, you should try to get involved in other security communities that are closer to you. InfraGard, OWASP, the Kali Linux forums, and many others are great resources for you.
Reading this book and joining a security community are great ways to expand your horizons and learn additional and advanced security concepts. Following a thread or seeing a talk will often spur an interest in a specific security topic.
Once you have mastered the basics, you can look at diving more deeply into a particular area of security. Most people learn the basics, and then tend to specialize in a particular area. This is not something you have to choose today, and becoming specialized in a single area does not preclude you from becoming specialized in other areas. However, in general, most people tend to be highly focused with an advanced knowledge in one or two areas of security. The list below is just a small sample of topics that you can specialize in. It is not meant to be all-inclusive but rather to provide you with a sample of the various areas that require advanced training:
Offensive security/Ethical hacking
Web application security
Where Do I Go from Here?
After reading this book, you may be hungry to learn more about a particular topic, step, or technique that was discussed. Now that you have mastered the basics, there should be many additional doors open to you. If you have truly studied, practiced, and understood the basic material presented in this book, you are equipped to tackle more advanced training.
Remember one of the main motivations for writing a book like this was not to turn you into an elite hacker or penetration tester but rather to provide you with a springboard for advancing your knowledge. With a firm understanding of the basics, you should feel confident and prepared to take on advanced training in any of the areas we discussed. There are many opportunities for you to take your skill to the next level. Regardless of which area you choose to explore next, I would strongly encourage you to build a solid foundation by beefing up your knowledge of programming and networking.
If you are interested in a more “hands-on” learning approach, there are many great two- to five-day security boot camps available to you. These classes are often expensive and very labor-intensive, but often highly worth their price of admission. The Black Hat conference usually offers a series of highly specialized and focused classes delivered by some of the most well-known names in security today. There are literally dozens of security topics and specializations to choose from these events. The trainings change from year to year, but you can find them on the Black Hat website at http://www.blackhat.com.
The crew responsible for creating and distributing Kali Linux also offers a hands-on highly intense series of classes. These classes will challenge you and push you by making you work through a series of realistic scenarios.
Even traditional universities are beginning to get into the security mode today. Just a few years ago, it was difficult to find any security-related curriculum. Now, most universities offer at least one class or devote time during a class to cover some security. Dakota State University (DSU) (where I teach) in Madison, SD, offers several on-campus and online degrees which are dedicated entirely to security. DSU has two Bachelor’s Degrees available: Cyber Operations and Network Security Administration, a Master’s Degree in Information Assurance, and even a Doctorate of Science degree in Information Assurance.
If you are interested in pursuing a security-related degree through a higher education institution, you are highly encouraged to attend an NSA-accredited Center of Academic Excellence. These programs are information assurance education degrees that have undergone a designation by the National Security Agency or the Department of Homeland Security to verify the value of the curriculum. You can find more about this program at http://www.nsa.gov/ia/academic_outreach/nat_cae/index.shtml. Finally, if you want to attend a school where “offensive security” is taken very seriously and has undergone a rigorous external review, look for programs, which have been designated as National Centers of Excellence in Cyber Operations. You can find more details on the designation as well as the exclusive list of these schools at http://www.nsa.gov/academia/nat_cae_cyber_ops/nat_cae_co_centers.shtml.
It is well worth your time to take a close look and examine the various security testing methodologies including the Open Source Security Testing Methodology Manual and the Penetration Testing Execution Standard (PTES). This book focused on the specific tools and methods used in a penetration test. The PTES, which is my personal favorite, provides security professionals with a well-defined, mature framework that can be implemented in conjunction with many of the topics covered in this book. I like PTES because it is put together by working professionals, provides technical details, and is very thorough. You can find the details here: http://www.pentest-standard.org.
Another great penetration testing methodology can be found at http://www.vulnerabilityassessment.co.uk. The Penetration Testing Framework (PTF) is an excellent resource for penetration testers and security assessment teams. The PTF includes assessment templates as well as a robust list of tools that can be used to conduct each phase.
If you read this book from front to back, take a minute to stop and consider all that you learned. At this point, you should have a solid understanding of the various steps involved in a typical penetration test and the tools required to complete each of the steps. More importantly, you should understand how the penetration testing process flows and how to take the information and output from each of the phases and feed those results into the next phase. Many people are eager to learn about hacking and penetration testing, but most newcomers only understand how to run a single tool or complete a single step. They refuse to see the big picture and often end up spinning their wheels in frustration when their tool does not work or provides unexpected results. This group does not realize how the entire process works and how to leverage the power of each phase to strengthen the phases that come after it.
For those of you who stuck with the book, completed each of the examples, and gave an honest effort at following along, at the very least, this book should have provided you with the knowledge and ability to see the big picture and understand the importance of each phase.
You also now should have the ability to answer the question posed to you in a scenario at the beginning of Chapter 2:
Assume you are an ethical penetration tester working for a security company. Your boss walks over to your office and hands you a piece of paper. “I just got off the phone with the CEO of that company. She wants my best employee to Pen Test his company—that’s you. Our Legal Department will be sending you an e-mail confirming we have all of the proper authorizations and insurance.” You nod, accepting the job. He leaves. You flip over the paper, a single word is written on the paper, “Syngress”. It is a company you have never heard of before, and no other information is written on the paper.
The Circle of Life
One of the greatest attributes of penetration testing and hacking is that you never reach the end. Just about the time you master a particular topic or technique, someone develops a new method, attack, or procedure. That is not to say that your original skill set is obsolete. On the contrary, a solid understanding of the basics provides you with a lifelong foundation for learning the advanced topics and staying current with the rapid pace of change.
I always enjoy hearing from readers, so feel free to send me an e-mail or hit me up on twitter: @pengebretson
Enjoy the journey!
This chapter focused on the importance of writing the penetration testing report and examined specific details about what needs to be included and potential pitfalls for hackers who have never written a penetration testing report. The importance of presenting a quality report to the client was emphasized. It concluded with suggestions about where you can go to further enhance your hacking skills once you have mastered the basics. Specific recommendations for getting advanced training and becoming part of the security community were also outlined.