I’m not sure I’ve mentioned this before, but did you guys know I worked in a body shop for most of my teenage years? It was an awesome experience taking in cars that had been involved in an accident or subjected to the horrors of rust and the elements, and returning them back as brand-new, shiny, beautiful works of art. My boss, Rob, was an awesome guy to work for and taught me more about cars and bodywork than I ever even knew existed. I learned tons about automotive bodywork, chemistry, air quality, and paint.

The process for these cars, regardless of what had happened to them, was roughly the same. After Rob had prepared an estimate and the owner agreed for us to do the work, we’d wash everything down as best we could (grease, oil, and other contaminants don’t mix well with paint) and then move the car into the shop. Next, we’d take everything off the car we could possibly take off—bumpers, chrome, decals, mirrors…everything—around the area being worked on (if it was a full paint job, it all came off). Precautions were taken to protect areas that weren’t being worked on or that couldn’t (shouldn’t) be touched. We then moved to my favorite part—the rough work on the body. Sandblasting, welding, pounding, and shaping metal with big hammers and hydraulic machinery—all of it so manly, I’m sitting here grunting like Tim “The Tool Man” Taylor in fond memory.

All this would be followed by mid work: things like Bondo application (in very small quantities and only where appropriate), sanding, and prepping. This work was delicate in nature because it had to be perfect before any paint was applied. A small dip in the sanding wouldn’t seem to be an issue until gloss paint over it made it appear to be a valley of despair and shoddy workmanship later, and a missed scratch—even in an area we weren’t focused on—would look ghastly with paint sprayed over it. After this, we sprayed a solid coat of primer and wet sanded it down to perfection. A drying session and a blowout of the entire paint room (to remove all dirt, dust, and debris) followed, with a final wipe down (for oils and such) and inspection before the paint was applied.

Finally, when the painting was done and cured, all the stuff we took off had to be put back on, and the car would get detailed. But, just before this, Rob would make a final inspection. He covered every square inch of the car, much like a detective at a crime scene, looking for anything we’d missed—anything that wasn’t absolutely perfect. When I was learning the trade, he’d stop and point out flaws, explaining to me exactly what we’d missed and how we’d fix it. And it always surprised me how, after all that attention to detail and process beforehand, there were always a few things I missed and a few things I could’ve gotten better.

And so, dear reader, you find yourself looking at the nearly finished virtual body job we’ve been working on thus far. We’ve done pretty good work, I think, and have a great product here to be proud of. But if we take a few minutes and look back at everything, maybe we can find a few things we left out, or maybe some things that just need a bit more explanation to make it all fall into place. Hopefully nothing is really bad, because I’d hate for you to hear Rob yelling about shoddy craftsmanship.

We’ve covered everything that should be relevant for your upcoming exam, a few things that might make you a better ethical hacker, and even some stuff you might’ve found just plain cool. I hope what’s covered here results in your employment as an ethical hacker, where you’ll be doing good work for the betterment of your society. Sure, that may sound corny to some of you, but I truly believe it. And I know that if you believe your profession is making the world a better place, the pride you have in it will result in you becoming better and better at it each and every day. Before too long, you’ll look back on this little book like one of those English 101 books from college and wonder at how far you’ve come. So, let’s take just a few paragraphs here and look back via a discussion on the penetration test. The pen test is where you’ll put into practice what you’ve read in a book and what you’ve learned on your own through practice and experience. I promise this won’t take long; it’s a short chapter, and I’m pretty sure you deserve a break.

Methodology and Steps

Much has been made so far in this book about following steps and taking a logical approach to hacking. I can honestly say that most of that is purely for your exam—for your “book knowledge,” if you will. Hackers will take advantage of any opportunity as it presents itself, and they’ll always look for the easy way in. Why bother running through all the steps of a hacking attack on a machine that’s either too secured to allow a breach (easily and within a decent timeframe) or doesn’t present a pot of gold at the end of the attack rainbow? I think too many people have the idea that ethical hacking/pen testing is a cookie-cutter, one-size-fits-all operation. In reality, each situation, and each client, is different. What works for one client may not work for another, and tests and deliverables that make one client happy might result in a lawsuit from another.

However, all that said, methodology isn’t all bad, especially when you’re first starting out. A methodology, when not held too rigidly in a book-smart, absolutely annoying, college-graduate “I KNOW EVERYTHING” manner, can give you a good guide and serve as a reminder to cover everything. Heck, EC-Council isn’t even alone in suggesting one—SANS recommends much the same methodology (https://www.sans.org/reading-room/whitepapers/auditing/conducting-penetration-test-organization-67). The idea is to make sure you cover everything—which is exactly what we’re going to do here. Buckle up, and let’s ride.

The Security Assessments

Every organization on the planet that has any concern whatsoever for the security of its resources must perform various security assessments, and some don’t have a choice, if they need to comply with FISMA or other various government standards (see Figure 13-1). In CEH parlance, a security assessment is any test that is performed in order to assess the level of security on a network or system. The security assessment can belong to one of three categories: a security audit, a vulnerability assessment, or a penetration test.

Figure 13-1 NIST and FISMA logos

A security audit is policy and procedure focused. It tests whether the organization is following specific standards and policies they have in place. After all, what good is having the policy if no one in the organization knows about it or follows what it says? A vulnerability assessment scans and tests a system or network for existing vulnerabilities but does not intentionally exploit any of them. This vulnerability assessment is designed to uncover potential security holes in the system and report them to the client for their action. This assessment does not fix or patch vulnerabilities, nor does it exploit them—it simply points them out for the client’s benefit.

A penetration test, on the other hand, not only looks for vulnerabilities in the system but actively seeks to exploit them. The idea is to show the potential consequences of a hacker breaking in through unpatched vulnerabilities. Pen tests are carried out by highly skilled individuals pursuant to an agreement signed before testing begins, and it’s paramount you understand that concept. Nothing happens before you have a signed, sealed agreement in place. Nothing. This agreement should spell out the limitations, constraints, and liabilities between the organization and the penetration test team, and is designed to maximize the effectiveness of the test itself while minimizing operational impact.

Although most people automatically think of this as a “get out of jail free” card, it’s much more than that. You’ll need to cover everything you can think of and a lot of things you haven’t. For example, you might agree up front that no denial-of-service attacks are to be performed during the test, but what happens if your port scanner accidentally brings down a server? Will you be liable for damages? In many cases, a separate indemnity form releasing you from financial liability is also necessary.

Defining the project scope will help to determine whether the test is a comprehensive examination of the organization’s security posture or a targeted test of a single subnet/system. You may also find a need to outsource various efforts and services. In that case, your service level agreements (SLAs) need to be iron-clad in defining your responsibility in regard to your consultant’s actions. In the event of something catastrophic or some serious, unplanned disruption of services, the SLA spells out who is responsible for taking action to correct the situation. And don’t forget the nondisclosure terms: most clients don’t want their dirty laundry aired and are taking a large risk in agreeing to the test in the first place.

If you’d like to see a few examples of pen test agreement paperwork, just do some Google searching. SANS has some great information available, and many pen test providers have basics about their agreements available. Keep in mind you won’t find any single agreement that addresses everything—you’ll have to figure that out on your own. Just be sure to do everything up front, before you start testing.

Speaking of pen tests overall, there are basically two types of penetration tests defined by EC-Council: external and internal. An external assessment analyzes publicly available information and conducts network scanning, enumeration, and testing from the network perimeter, usually from the Internet. An internal assessment, as you might imagine, is performed from within the organization, from various network access points. Obviously, both could be part of one overall assessment, but you get the idea.

We’ve covered black-box, white-box, and gray-box testing already, so I won’t beat you over the head with these again. However, just to recap, black-box testing occurs when the attacker has no prior knowledge of the infrastructure at all. This testing takes the longest to accomplish and simulates a true outside hacker. White-box testing simulates an internal user who has complete knowledge of the company’s infrastructure. Gray-box testing provides limited information on the infrastructure. Sometimes gray-box testing is born out of a black-box test that determines more knowledge is needed.

While we’re on the subject of colors, EC-Council wants you to know your test team has a specific color designation, depending on which side of the fence you’re working on during a war game. While you’re probably already aware of the “capture the flag” type contests you’ve no doubt seen at Black Hat, Defcon, SANS, or any other security event, there is a simulation that’s a step above that. Suppose you wanted the full experience—not only to see what the bad guys attacking you are doing but also how a security team responds. The military does it all the time, simulating an attacking force and having another group defend. In the virtual world, the same thing can be played out.

In this war game scenario, the two colors taking sides are red and blue. If you’re on a team simulating an attacking force, you’re considered to be red. The red team is the offense-minded group, simulating the bad guys in the world, actively attacking and exploiting everything they can find in your environment. In a traditional war game scenario, the red team is attacking black-box style, given little to no information to start things off. The blue team, on the other hand, is defensive in nature. They’re not out attacking things—rather, they’re focused on shoring up defenses and making things safe. Unlike the red teams, since blue teams are responsible for defense against the bad guys, they usually operate with full knowledge of the internal environment.

Finally, in this (pardon the monochromatic corollary here) black-and-white color-coded pen test teaming world, there are shades of gray. Or, in this case, shades of purple. The so-called purple team (terminology gaining wild popularity in the real world but may not be on your exam, yet) is dedicated to fulfilling both worlds. While a red team would perform an adversarial assessment and a blue team would be purely in a defensive posture, a purple team might perform a “cooperative vulnerability and penetration assessment” involving both sides in an effort to not only attack and identify issues, but to repair and advise along the way. The goal is to assist defenders and to do so with whatever information is available; in other words, the difference between “blue” and “red” in this scenario is in the cooperative versus adversarial nature: red is there to be the bad guys—to do what they would do, to look for the impacts they would want to have, and to test the defenses/responses—whereas blue is there to help.

Testing can also be further broken down according to the means by which it is accomplished. Automated testing is a point-and-shoot effort with an all-inclusive toolset such as Core Impact. This could be viewed as a means to save time and money by the client’s management, but it simply cannot touch a test performed by security professionals. Automated tools can provide a lot of genuinely good information but are also susceptible to false positives and false negatives, and they don’t necessarily care what your agreed-upon scope says is your stopping point. A short list of some automated tools is presented here:

•   Codenomicon   This is a toolkit for automated penetration testing that, according to the provider, eliminates unnecessary ad hoc manual testing: “The required expertise is built into the tools, making efficient penetration testing available for all.” Codenomicon’s penetration testing toolkit utilizes a unique “fuzz testing” technique that learns the tested system automatically. This is designed to help penetration testers enter new domains, such as VoIP assessment, or to start testing industrial automation solutions and wireless technologies.

•   Core Impact Pro   Probably the best-known all-inclusive automated testing framework, Core Impact Pro “takes security testing to the next level by safely replicating a broad range of threats to the organization’s sensitive data and mission-critical infrastructure—providing extensive visibility into the cause, effect and prevention of data breaches” (per the company’s site). Core Impact, shown in Figure 13-2, tests everything from web applications and individual systems to network devices and wireless (a vulnerability management function is found in the company’s Core Insight product). You can find multiple videos online showing this tool in action, or you can simply visit Core Security’s website and see what the company has cooked up for you (www.coresecurity.com/resources/videos). You might also want to visit your bank before looking into this tool—at $35K for a single annual license, it’s a pricey endeavor.

Figure 13-2 Core Impact

•   Metasploit   Mentioned several times already in this book, Metasploit (www.metasploit.com) is a framework for developing and executing exploit code against a remote target machine (the pay-for version is called Metasploit Pro and offers much more functionality). Metasploit offers a module called Autopwn that can automate the exploitation phase of a penetration test (after opening the console, type msf> use auxiliary/server/browser_autopwn). Autopwn can attempt to fingerprint a target browser and follow up with every exploit it believes will work against it. Although this is simple and easy, it can be quite noisy and can even crash the target’s browser, system, or services. The Rapid7 community has tons of assistance and videos on this (one example is found at https://community.rapid7.com/community/metasploit/blog/2015/07/15/the-new-metasploit-browser-autopwn-strikes-faster-and-smarter--part-1).

•   CANVAS   From Immunity Security (https://www.immunityinc.com/products/canvas/), CANVAS “makes available hundreds of exploits, an automated exploitation system, and a comprehensive, reliable exploit development framework to penetration testers and security professionals” (per the company’s website). Additionally, the company claims CANVAS’s Reference Implementation (CRI) is “the industry’s first open platform for IDS and IPS testing.”

Manual testing is still, in my humble opinion, the best choice for a true security assessment. It requires good planning, design, and scheduling, and it provides the best benefit to the client. Although automated testing definitely has a role in the overall security game, many times it’s the ingenuity, drive, and creativeness of the hacker that results in a true test of the security safeguards.

As for the actual test, EC-Council and many others have divided the actions taken into three main phases. In the pre-attack phase, you’ll be performing all the reconnaissance and data-gathering efforts we discussed earlier in this book. Competitive intelligence, identifying network ranges, checking network filters for open ports, and so on, are all carried out here. Also, running whois, DNS enumeration, finding the network IP address range, and Nmap network scanning all occur here. Other tasks you might consider include, but aren’t limited to, testing proxy servers, checking for default firewall or other network-filtering device installations or configurations, and looking at any remote login allowances.

In the attack phase, you’ll be attempting to penetrate the network perimeter, acquire your targets, execute attacks, and elevate privileges. Getting past the perimeter might take into account things such as verifying ACLs by crafting packets and checking to see whether you can use any covert tunnels inside the organization. On the web side, you’ll be trying XSS, buffer overflows, and SQL injections. After acquiring specific targets, you’ll move into password cracking and privilege escalation, using a variety of methods we’ve covered here. Finally, once you’ve gained access, it’s time to execute your attack code.

Finally, the post-attack phase consists of two major steps. First, there’s an awful lot of cleanup to be done. Anything that has been uploaded to the organization’s systems in the way of files or folders needs to be removed. Additionally, any tools, malware, backdoors, or other attack software loaded on client systems need to be taken off. And don’t forget the registry—any changes made there need to be reset to the original settings. The idea is to return everything to the pre-test state. Remember, not only are you not supposed to fix anything you find, but you’re also not supposed to create more vulnerabilities for the client to deal with.

And the second step in the post-attack phase? Well, that deals with the deliverables, which we’ll discuss in the next section. Before we do, though, we need to cover a couple other aspects of pen testing you may not have thought of. Remembering these steps and guidelines are great, but you may also be required to apply them, and some common sense, in a scenario on your exam. For example, it’s easy to remember you certainly wouldn’t do anything before you get an agreement and scope in place, but you might need to think about what you’d want to do or say before beginning the attack. If you’re asked to test for weak passwords, should you tell every user about it beforehand so they have a chance to fix their own before you test? Probably not. What about if you cause the IDS to go bonkers and alert? Should you stop your test and inform them? Probably so (continuing to test may interfere with defending against an actual attack), but it really depends on how far your agreement allows you to go.

And what happens if you find something during a test that shouldn’t be there? When do you contact the authorities, and do you do so with or without consent of the target organization? For example, suppose you are performing a pen test on a company’s environment and you discover a repository of pirated music and videos. Is it your job to report that? What if it’s social security numbers and PII in a location that’s not protected? How about illegal copies of software? In all of these scenarios, the answer is definitely no. Even though pirated music, movies, and software are illegal, you have no means to determine their source, nor any means at your disposal to determine if they were acquired illegally.

What if what you find, though, does indicate a crime? For example, what if you discover child porn on a machine, or an e-mail actively selling PII and credit card information? In both cases there seems to be no doubt a crime has occurred: U.S. federal law prohibits the possession of child pornography, and obtaining and using PII in a way that involves fraud or deception is also prohibited by law. However, each situation is unique, and your team should have procedures in place to deal with it—procedures spelled out specifically by the agreement addressing suspected criminal findings.

Failure to report a crime can oftentimes be considered a crime itself, but if you decide to play Inspector Clouseau and wind up reporting something on your own, you’re opening yourself to a world of hurt. Suppose you find something you think is criminal in nature and report it, only to see a court say it’s nothing and throw it out. Now the company will sue you for loss, and you can be charged with a variety of offenses. The best answer is to remember you’re not an officer of the law and it’s not your job to do their work for them. Follow what your team guidance is (somewhere along the line there should be follow-up to ensure appropriate law enforcement is involved) and stay within your agreements.

Security Assessment Deliverables

I know you’re probably going to hate hearing this, but I have to be truthful with you—just because you’re an ethical hacker performing security assessments for major clients doesn’t mean you’re off the hook paperwork-wise. The pen test you were hired to do was designed with one objective in mind: to provide the client with information they need to make their network safer and more secure. Therefore, it follows that the client will expect something in the form of a deliverable in order to take some action—something that will require you to practice your organizational, typing, and presentation skills. As our beloved tech editor is fond of saying, “Nobody gives a hoot how good you are at hacking. The only things customers care about are the findings, the impacts, and the analysis in the report or out-brief. A crappy team with a great report will be seen by customers as better than a great team with a crappy report.” Fundamentally, you are your report whether you like it or not, so if you thought you were getting into a paperwork-free, no-time-behind-the-desk job, my apologies.

Typically your test will begin with some form of an in-brief to the management. This should provide an introduction of the team members and an overview of the original agreement. You’ll need to point out which tests will be performed, which team members will be performing specific tasks, the timeline for your test, and so on. Points of contact, phone numbers, and other information—including, possibly, the “bat phone” number, to be called in the event of an emergency requiring all testing to stop—should all be presented to the client before testing begins. This is a thorough review of all expectations, for both the test team and the client—nobody leaves until everyone is in agreement and up to date.

After the test is complete, a comprehensive report is due to the customer. Each test and client is different, but here are some of the basics that are part of every report:

•   An executive summary of the organization’s overall security posture. (If you are testing under the auspices of FISMA, DIACAP, RMF, HIPAA, or some other standard, this summary will be tailored to the standard.)

•   The names of all participants and the dates of all tests.

•   A list of findings, usually presented in order of highest risk.

•   An analysis of each finding and recommended mitigation steps (if available).

•   Log files and other evidence from your toolset. This evidence should include tons of screenshots, because that’s what customers seem to want.

For an example of a standard pen test report template, see www.vulnerabilityassessment.co.uk/report%20template.html.

Guidelines

Seems like everything in networking and communications births some kind of standard and an organization to promote it. Pen testing methodology is really a different animal altogether, since by its very nature it’s not a prime candidate for in-depth standardization. But what about security testing and implementation in general? Absolutely. And that’s where the Open Source Security Testing Methodology Manual (OSSTMM) comes into play.

I know, I know—I can hear you screaming across the plains that Open Source doesn’t indicate a standard, per se. But just hang in there with me, because I’m going somewhere with this, and it’s something you’ll see referenced at least once on your exam. OSSTMM (pronounced “awestem” per the developers) was created by the Institute for Security and Open Methodologies (ISECOM, www.isecom.org) in 2001. It was started by a group of researchers from various fields as an effort to improve how security was tested.

OSSTMM is a peer-reviewed manual of security testing and analysis that results in fact-based actions that can be taken by an organization to improve security. Downloadable as a single (although massive) PDF file, OSSTMM tests legislative, contractual, and standards-based compliance. Because of the nature of security and its ever-changing discoveries and needs, it’s continually under development, so keeping up to date with the latest findings is a bonus. Joining the ISECOM-NEWS list allows you to learn about releases, updates, findings, and all sorts of goodies from the friendly research staff. Heck, they even have a Facebook page, if you’re so inclined.

Again, this isn’t a pen-test-based security testing standard necessarily, but it does, per the website, “provide a methodology for a thorough security test, known as an OSSTMM audit.” You won’t find EC-Council’s steps clearly defined here, as you will on your exam, but it does provide a pretty thorough look at a security test from beginning to end. If your organization is starting from scratch, this isn’t a bad place to start preparing and reading.

And don’t start thinking this is the only one—a simple Internet search for “pen test methodology” will show that’s not even close to true. Vulnerability Assessment.co.uk (www.vulnerabilityassessment.co.uk/Penetration%20Test.html) has been promoting a pen test walkthrough methodology for years. SANS (www.sans.org/reading-room/whitepapers/auditing/conducting-penetration-test-organization-67) has tons of reading material on the subject and promotes their own version. And don’t forget more specialized options: Open Web Application Security Project (OWASP) provides security information, including vulnerabilities and fixes, on web servers and applications for free (https://www.owasp.org/index.php/Main_Page).

More Terminology

Before you start yelling at the pages that this section seems out of place here, save your breath—I hate terminology, too, and I’m as sick of it as you are. As you’re more than aware by now, EC-Council has some interesting terminology for you to learn along the way. Some of it is useful, but most of it is just for memorization purposes for your exam—which you can immediately dump out of your neurons as soon as your test is over. This section, covering the players inside and outside an organization, is no exception, and I hesitated to even include it in this edition of the book.

You’re already familiar with the disgruntled employee, white hats, black hats, and the difference between an ethical hacker and a cracker. What you haven’t seen yet is the crazed, additional terminology categorizing the folks inside and outside the organization that EC-Council has cooked up for you. The good news is, as of today as I sit here writing this, I have not seen any of these terms in more than a passing reference in official courseware or practice exams. The bad news is, they were a big part of versions 7 and 8 of the exam, so I have no real idea if ECC will keep them in or not. In the interest of covering everything, though, I have to include them.

EC-Council describes four different categories of insider threats, based on the level of access the employee has: pure insider, insider associate, insider affiliate, and outside affiliate. The pure insider is the easiest to understand because it’s exactly what it sounds like: an employee with all the rights and access associated with being employed by the company. Typically, pure insiders already have access to the facility, with a badge of some sort, and a logon to get access to the network. One of the biggest problems from a security perspective with pure insiders isn’t that they exist—after all, your company really does need people to get the work done—it’s that their privileges are often assigned at a higher level than are actually required to get their work done.

Next up in our romp through crazed terminology is the insider associate. This refers to someone with limited authorized access, such as a contractor, guard, or cleaning services person. These folks aren’t employees of the company, and they certainly do not need or have full access, but they have physical access to the facility to work. While they’re not allowed network access, the fact they’re already in the building is a concern for the security professional trying to cover all bases. Not only are the physical records sometimes accessible, not to mention the plethora of dumpster-diving material, but physical access to a system usually guarantees a hacker, given enough time, can access what she needs.

The third category defined is the insider affiliate, which is more than likely to give you fits with memorization. An inside affiliate is a spouse, friend, or client of an employee who uses the employee’s credentials to gain access. The key to this isn’t the person carrying out the attack so much as it is the credentials used to do it. For example, employee Joe’s wife, Mary, isn’t an employee; however, if she’s using Joe’s credentials, for all intents and purposes she is an insider. To the network, physical access restriction areas, and any computer she grabs hold of, Mary appears to be Joe, the trusted insider.

And finally, the last category is one that should be easy to memorize. The outside affiliate is someone who is outside the organization, unknown and untrusted, who uses an open access channel to gain access to an organization’s resources. For example, remember during our chapter on wireless how we spent so much time talking about where you place your wireless access points? If you place one in an easily accessible area and don’t secure it properly, an outside affiliate can gain unauthorized access to your networks and resources. Just remember, if it’s an employee or someone who knows the employee, it’s an insider—if it’s not, it’s an outsider.

And so, dear reader, we’ve reached the end of your testable material. I promised I’d keep this chapter short and to the point, and I believe I have. A lot of the information in this chapter is a review of items we’ve already discussed, but it’s important to know for both your exam and your real-world exploits. I sincerely hope I’ve answered most of your questions and eliminated some of the fear you may have had in tackling this undertaking.

Best of luck to you on both your exam and your future career. Practice what we’ve talked about here—download and install the tools and try exploits against machines or VMs you have available in your home lab. And don’t forget to stay ethical! Everything in this book is intended to help you pass your upcoming exam and become a valued pen test member, not to teach you to be a hacker. Stay the course and you’ll be fine.

Chapter Review

Security assessments can be one of two types: a security audit (vulnerability assessment) or a penetration test. The security audit scans and tests a system or network for existing vulnerabilities but does not intentionally exploit any of them. This assessment is designed to uncover potential security holes in the system and report them to the client for their action. It does not fix or patch vulnerabilities, nor does it exploit them. It only points them out for the client’s benefit.

A penetration test actively seeks to exploit vulnerabilities encountered on target systems or networks. This shows the potential consequences of a hacker breaking in through unpatched vulnerabilities. Penetration tests are carried out by highly skilled individuals according to an agreement signed before testing begins. This agreement spells out the limitations, constraints, and liabilities between the organization and the penetration test team.

Penetration tests consist of two types of assessment: external and internal. An external assessment analyzes publicly available information and conducts network scanning, enumeration, and testing from the network perimeter—usually from the Internet. An internal assessment is performed from within the organization, from various network access points.

Black-box testing occurs when the attacker has no prior knowledge of the infrastructure at all (your scope is defined, and you’ll be provided the minimal amount of information required). This testing takes the longest to accomplish and simulates a true outside hacker. White-box testing simulates an internal user who has complete knowledge of the company’s infrastructure. Gray-box testing provides limited information on the infrastructure. Sometimes gray-box testing is born out of a black-box test that determines more knowledge is needed.

Testing can also be further broken down according to the way it is accomplished. Automated testing uses an all-inclusive toolset. Automated tools can provide plenty of information and many legitimate results for a lesser price than manual testing with a full test team. However, they are also susceptible to false positives and false negatives and don’t always stop where they’re supposed to (software can’t read your agreement contract). Manual testing is the best choice for security assessment. It requires good planning, design, and scheduling, and it provides the best benefit to the client. Manual testing is accomplished by a pen test team, following the explicit guidelines laid out before the assessment.

There are three main phases to a pen test. In the pre-attack phase, reconnaissance and data-gathering efforts are accomplished. Gathering competitive intelligence, identifying network ranges, checking network filters for open ports, and so on, are all carried out in this phase. Running whois, DNS enumeration, finding the network IP address range, and network scanning are all examples of tasks in this phase.

Attempting to penetrate the network perimeter, acquire targets, execute attacks, and elevate privileges are steps taken in the attack phase. Verifying ACLs by crafting packets, checking to see whether you can use any covert tunnels inside the organization, and using XSS, buffer overflows, and SQL injections are all examples of tasks performed in this phase. After acquiring specific targets, you’ll move into password cracking and privilege escalation, using a variety of methods. Finally, once you’ve gained access, it’s time to execute your attack code.

The post-attack phase consists of two major steps. The first step involves cleaning up your testing efforts. Anything that has been uploaded to the organization’s systems in the way of files or folders needs to be removed. Any tools, malware, backdoors, or other attack software loaded on the client’s systems need to be taken off. Any registry changes you’ve made need to be reset to their original settings. The goal of this phase is to return everything to the pre-test state.

The second step involves writing the pen test report, due after all testing is complete. The pen test report should contain the following items:

•   An executive summary of the organization’s overall security posture. (If you’re testing under the auspices of FISMA, DIACAP, HIPAA, or some other standard, this will be tailored to the standard.)

•   The names of all participants and the dates of all tests.

•   A list of findings, usually presented in order of highest risk.

•   An analysis of each finding and the recommended mitigation steps (if available).

•   Log files and other evidence from your toolset.

Questions

1.   A security staff is preparing for a security audit and wants to know if additional security training for the end user would be beneficial. Which of the following methods would be the best option for testing the effectiveness of user training in the environment?

A.   Vulnerability scanning

B.   Application code reviews

C.   Sniffing

D.   Social engineering

2.   What marks the major difference between a hacker and an ethical hacker (pen test team member)?

A.   Nothing.

B.   Ethical hackers never exploit vulnerabilities; they only point out their existence.

C.   The tools they use.

D.   The predefined scope and agreement made with the system owner.

3.   Which of the following best describes a blue team?

A.   Security team members defending a network

B.   Security team members attacking a network

C.   Security team members with full knowledge of the internal network

D.   A performance group at Universal Studios in Orlando

4.   In which phase of a penetration test is scanning performed?

A.   Pre-attack

B.   Attack

C.   Post-attack

D.   Reconnaissance

5.   Which type of security assessment notifies the customer of vulnerabilities but does not actively or intentionally exploit them?

A.   Vulnerability assessment

B.   Scanning assessment

C.   Penetration test

D.   None of the above

6.   Which of the following would be a good choice for an automated penetration test? (Choose all that apply.)

A.   Nmap

B.   Netcat

C.   Core Impact

D.   CANVAS

7.   Which of the following tests is generally faster and costs less but is susceptible to more false reporting and contract violation?

A.   Internal

B.   External

C.   Manual

D.   Automatic

8.   Joe is part of a penetration test team and is starting a test. The client has provided him a system on one of their subnets but did not provide any authentication information, network diagrams, or other notable data concerning the systems. Which type of test is Joe performing?

A.   External, white box

B.   External, black box

C.   Internal, white box

D.   Internal, black box

9.   In which of the following would you find in a final report from a full penetration test? (Choose all that apply.)

A.   Executive summary

B.   A list of findings from the test

C.   The names of all the participants

D.   A list of vulnerabilities patched or otherwise mitigated by the team

10.   Which security assessment is designed to check policies and procedures within an organization?

A.   Security audit

B.   Vulnerability assessment

C.   Pen test

D.   None of the above

11.   Which of the following best describes a red team?

A.   Security team members defending a network

B.   Security team members attacking a network

C.   Security team members with full knowledge of the internal network

D.   Security team members dedicated to policy audit review

Answers

1.   D. Social engineering is designed to test the human element in the organization. Of the answers provided, it is the only real option.

2.   D. Pen tests always begin with an agreement with the customer that identifies the scope and activities. An ethical hacker will never proceed without written authorization.

3.   A. Blue teams are defense-oriented. They concentrate on preventing and mitigating attacks and efforts of the red team/bad guys.

4.   A. All reconnaissance efforts occur in the pre-attack phase.

5.   A. Vulnerability assessments (a.k.a. security audits) seek to discover open vulnerabilities on the client’s systems but do not actively or intentionally exploit any of them.

6.   C, D. Core Impact and CANVAS are both automated, all-in-one test tool suites capable of performing a test for a client. Other tools may be used in conjunction with them to spot vulnerabilities, including Nessus, Retina, SAINT, and Sara.

7.   D. Automatic testing involves the use of a tool suite and generally runs faster than an all-inclusive manual test. However, it is susceptible to false negatives and false positives and can oftentimes overrun the scope boundary.

8.   D. Joe is on a system internal to the network and has no knowledge of the target’s network. Therefore, he is performing an internal, black-box test.

9.   A, B, C. The final report for a pen test includes an executive summary, a list of the findings (usually in order of highest risk), the names of all participants, analysis of findings, mitigation recommendations, and any logs or other relevant files.

10.   A. A security audit is used to verify security policies and procedures in place.

11.   B. Red teams are on offense. They are employed to go on the attack, simulating the bad guys out in the world trying to exploit anything they can find.