Certified Ethical Hacker (CEH) Study Guide

Chapter 1. Getting Started: Essential Knowledge

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 1st chapter of the final book.

If you have comments about how we might improve the content and/or examples in this book, or if you notice missing material within this chapter, please reach out to the editor at [e-mail].

A couple years back, my ISP point-of-presence router, comfortably nestled in the comm-closet-like area I’d lovingly built just for such items of IT interest, decided it had had enough of serving the humans and went rogue on me. It was subtle at first—a stream dropped here, a choppy communication session there—but it quickly became clear Skynet wasn’t going to play nicely, and a scorched-earth policy wasn’t off the table.

After battling with everything for a while and identifying the culprit, I called the handy help desk line to get order a new router to install myself, or a friendly in-home visit to replace it. After answering the phone and taking a couple of basic, and perfectly reasonable pieces of information, the friendly help desk employee started asking me what I considered to be ridiculous questions: “Is your power on? Is your computer connected via a cable or wireless? Is your wireless card activated? Because sometimes those things get turned off in airplane mode.” And so on. I played along nicely for a little while. I mean, look, I get it: they have to ask those questions. But after 10 or 15 minutes, I lost patience and just told the guy what was wrong. He paused, thanked me, and continued reading the scroll of questions no doubt rolling across his screen from the “Customer Says No Internet” file.

I finally got a new router ordered, which was delivered the very next day at 8:30 in the morning. Everything finally worked out, but the whole experience came to mind as I sat down to start writing this book. I got to looking at the course curriculum and chapter layouts, then thought to myself, “What are you thinking? Why are you telling them about networking and the OSI model? You’re the help desk guy here.”

Why am I telling you all this? Because I have to. I’ve promised to cover everything here--at least, as much as I can, given the moving target this certification presents). Although you shouldn’t jump into study material for the exam without already knowing the basics, we’re all human and some of us will. But don’t worry, dear reader, I have no intention of boring you to death with information I’m certain most of you already know. Instead, I’m going to do my best to focus as much as possible on the details you’ll need as you study for this exam.

That said, some of what’s covered here – the OSI reference model, which PDUs are at what level, and why you should care – is simply bedrock information we’ve got to get through before diving into the more exciting material. This chapter probably includes some inanely boring and mundane information that is about as exciting as that laundry you have piled up waiting to go into the machine, but it has to be said, and you’re the one to hear it. I’ll cover the many terms you’ll need to know, including just what an ethical hacker is supposed to be. Maybe I’ll even hit on a couple things you don’t already know.

Security 101

If you’re going to pursue an ethical hacking certification, you’ll want the fundamental security definitions and terminology right at the starting line. I’m not going to cover everything involved in IT security here—it’s simply too large a topic, we don’t have space, and you won’t be tested on every element anyway—but there is a foundation of 101-level knowledge you should have before wading out of the shallow end. This chapter covers the terms you’ll need to know to sound intelligent when discussing security matters intelligently. And, perhaps just as importantly, I’ll also cover some basics of TCP/IP networking. After all, if you don’t understand the language, how are you going to work your way into the conversation?

Essentials

Before we can get into what a hacker is and how you become one, we need to cover some security and network basics that will help you on your exam. Some of this section is simply basic memorization, some of it is common sense, and some of it is, or should be, just plain easy. You’re really supposed to know this stuff already, and you’ll see it again and again throughout this book, but it’s truly bedrock and I would be remiss if I didn’t at least provide a jumping-off point.

The OSI Reference Model

Most of us would rather take a ballpeen hammer to our toenails than hear about the OSI reference model again. It’s taught up front in every college networking class, so we’ve all heard it a thousand times over. That said, those of us who have been around for a while and have taken a certification test or two also understand it usually results in a few easy test answers—provided you understand what they’re asking for. I’m not going to bore you with the same stuff you’ve heard or read a million times before since, as stated earlier, you’re supposed to know this already. What I am going to do, though, is provide a quick rundown to refresh your memory.

I thought long and hard about the best way to go over this topic again for our review, wondering aloud how we could discuss actions, protocols, and even what name the data is given at a specific layer (the protocol data unit (PDU)) without boring everyone to tears. I landed on an idea: I’d ditch the same old boring method of talking this through and instead talk through building a network from scratch in our minds/here on paper. Instead, let’s look at the 10,000-foot overhead view of a communications session between two computers depicted in the OSI reference model through the lens of building a network—specifically, by trying to figure out how you would build a network from the ground up. So, step in the Wayback Machine with Sherman, Mr. Peabody, and me, and let’s go back in time to before networking was invented. How would you do it?

Note

My stalwart editor pointed out to me that some of you may have no idea who Sherman or Mr. Peabody was, and I should provide context. To enrich your life and make yourself a better person, go find an old television cartoon called The Adventures of Rocky and Bullwinkle and Friends, and search out the episodes holding “Peabody’s Improbable History.” You’ll be wildly entertained, and possibly learn something, as you find Sherman and Mr. Peabody hopping through history in their wacky adventures.

First, looking at those two computers sitting there wanting to talk to one another, you might consider the basics of what is right in front of your eyes: What would you use to connect your computers so they can transmit signals? In other words, what media would you use? There are several options, such as copper cabling, glass tubes, even radio waves, among others. And depending on which one of those you pick, you’re going to have to figure out how to use it to transmit useable information. How will you get an electrical signal on the wire to mean something to the computer on the other end? What part of a radio wave can you use to spell out a word or a color? On top of all that, you’ll need to figure out connectors, interfaces, and how to account for interference. And that’s just Layer 1 (the physical layer), where everything is simply bits—that is, ones and zeroes. The layers, and examples of the protocols you’d find in them, are shown in Figure 1-1.

Figure 1-1. OSI reference model

The Data Link layer (Layer 2) then helps answer the questions involved in growing your network. For example, if you decide to allow more than two nodes to join, how do you handle addressing? With only two systems, it’s no worry—everything sent is received by the guy on the other end—but if you add three or more to the mix, you’re going to have to figure out how to send the message with a unique address. And if your medium is shared, how will you guarantee everyone gets a chance to talk, and that no one’s message jumbles up anyone else’s? Layer 2 handles this using frames, which encapsulate all the data handed down from the higher layers. Frames hold addresses that identify a machine inside a particular network.

Note

Ethernet (IEEE 802.3) is by far the most commonly implemented Layer 2 standard.

And what happens if you want to send a message out of your network? It’s one thing to set up addressing so that each computer knows where all the other computers in the “neighborhood” reside, but sooner or later you’re going to want to send a message to another neighborhood—maybe even another city. And you certainly can’t expect each computer to know the address of every other computer in the whole world. This is where Layer 3 steps in with the packet used to hold network addresses and routing information. Packets work a lot like postal codes on an envelope. While the “street address” (the physical address from Layer 2) is used to define the recipient inside the physical network, the network address from Layer 3 tells routers along the way which “neighborhood” (network) the message is intended for.

Once you have addressing concerns under control, other considerations now come into play, like reliable delivery and flow control. Do you want a message just blasting out without having any idea if it made it to the recipient? Then again, depending on what the message is about and the data it carries, that might turn out to be a good idea. On top of all that, you definitely don’t want to overwhelm the medium’s ability to handle the messages you send, so maybe you might not want to put the giant boulder of the message onto our media all at once, when chopping it up into smaller, more manageable pieces makes more sense. The next layer, Transport, handles this and more for you. In Layer 4, the segment handles reliable end-to-end delivery of the message, along with error correction (by retransmitting missing segments) and flow control.

At this point, you’ve set the stage for success. You have a medium to carry a signal and you’ve figured how to encode that signal onto that medium. You’ve handled addressing inside and outside your network, and you’ve taken care of things like flow control and reliability. Now it’s time to look upward, toward the machines themselves, and make sure they know how to do what they need to do.

The next three layers - from the bottom up: Session (Layer 5) , Presentation (Layer 6), and Application(Layer 7) - handle the data itself. The Session layer is somewhat of a theoretical entity, with no real manipulation of the data itself—its job is to open, maintain, and close a session. The Presentation layer is designed to put a message into a format all systems can understand. For example, an email crafted in Microsoft Outlook may not necessarily be received by a machine running Outlook, so for delivery across a network it must be translated into something any receiver can comprehend—like pure ASCII code (which effectively represents characters on the keyboard as a series of bits).

The Application layer holds all the protocols that allow a user to access information on and across a network. For example, File Transfer Protocol (FTP) allows users to transport files across networks, Simple Mail Transport Protocol (SMTP) provides for e-mail traffic, and HyperText Transfer Protocol (HTTP) allows you to surf the Internet at work while you’re supposed to be doing something else. These three layers make up the “data layers” of the stack, and they map directly to the Application layer of the TCP/IP stack. In these three layers, the protocol data unit (PDU) is referred to as data.

Warning

Your OSI knowledge won’t be tested with questions as simple as what PDU goes with which layer. Rather, you’ll be asked questions that test your knowledge of the model; knowing what happens at a given layer will assist you in remembering the tool or protocol the question is asking about. Mnemonics can help your memory: “All People Seem To Need Daily Planning” will keep the layers straight, and “Do Sergeants Pay For Beer” will match up the PDUs with the layers.

TCP/IP Overview

Keeping in mind you’re supposed to know this already, we’re not going to spend an inordinate amount of time on this subject. That said, it’s vitally important to your success that the basics of TCP/IP networking are as ingrained in your neurons as other important aspects of your life, like maybe Mom’s birthday, the size and bag limit on redfish, the proper ratio of bourbon to anything you mix it with, and the proper way to place toilet paper on the roller (pull paper down, never up). This will be a quick preview, and we’ll revisit (and repeat) this in later chapters.

TCP/IP is a set of communications protocols that allows hosts on a network to talk to one another. This suite of protocols is arranged in a layered stack, much like the OSI reference model, with each layer performing a specific task. Figure 1-2 shows the TCP/IP stack.

Figure 1-2. TCP/IP stack

In keeping with the way this chapter started, let’s avoid a lot of the same stuff you’ve probably heard a thousand times already and simply follow a message from one machine to another through a TCP/IP network. This way, I hope to hit all the basics you need without boring you to tears and causing you to skip the rest of this chapter altogether. Keep in mind there is a whole lot of simultaneous goings-on in any session, so I may take a couple liberties to speed things along. So buckle up, and let’s try to see how these layers and protocols work together for a common activity by considering an intentionally simplified example of User Joe on a web browser. We’ll watch him start a request, create a transport layer segment, use that as data to create a packet, then cram all that into a frame for delivery.

Suppose, for example, user Joe wants to get ready for the University of Alabama football season opener and decides to do a little online shopping for his favorite gear. He begins by opening his browser and typing in a request for a website. His computer looks at the data request from the browser and determines it cannot answer the request internally—that is, not locally to Joe’s system. Why? Because the browser wants a page that is not stored locally. Joe’s computer then searches for a network entity to answer the request, chooses the protocol on which it knows the answer will come back (in this case, port 80 for HTTP), and starts putting together what will become a session—a bunch of segments sent back and forth to accomplish a goal.

Since this is an Ethernet TCP/IP network, Joe’s computer talks to other systems using a format of bits arranged in specific order. These collections of bits in a specific order are called frames (Figure 1-3 shows a basic Ethernet frame). Frames are built from the inside out, and rely on information ‘handed down’ from upper layers. To build this frame for delivery, Joe’s operating system is going to go through multiple steps to create it from the inside out, starting with the segment and packet…

First, the Application layer will hand down an HTTP request (the actual data for the frame) to the Transport layer. At the Transport layer, Joe’s computer looks at the HTTP request and (because it knows HTTP usually works this way) understands this needs to be a connection-oriented session, with stellar reliability to ensure Joe gets everything he asks for without losing anything. It calls on the Transmission Control Protocol (TCP) for that. TCP will then use a series of messages to set up a communications session with the end station before any data can ever be sent, including a three-step handshake to get things going. This handshake includes a Synchronize segment (SYN), a Synchronize Acknowledgment segment (SYN/ACK), and an Acknowledgment segment (ACK). The first of these—the SYN segment asking the other computer whether it’s awake and wants to talk—gets handed down to the Internet layer for addressing.

Figure 1-3. An Ethernet frame

Warning

The three-step handshake – how it works, the order in which it occurs, and what each of the packets themselves accomplishes – is vital to your success, both on the exam and in your efforts as an ethical hacker.

This layer needs to figure out what network the request will be answered from (after all, there’s no guarantee it’ll be local—it could be anywhere in the world), and is called a name resolution process. It’s carried out no matter which operating system you’re working on, but for this example, let’s suppose Joe is using a Microsoft Windows operating system, which uses several steps to find the correct location to send the request. The system first verifies that the name in the request isn’t its own – after all, how silly would it be to send a request out to the network when the user is asking YOU to answer? Then it checks a local file, the HOSTs file, to see if there are any entries that match. The HOSTs file is a plain-text list of names and corresponding IP addresses designed to speed up the name resolution process, so the system doesn’t have to go external. If it finds no entry in the HOSTs file matching the request name, the system will then check its own DNS cache to see if it has looked up this name in the past. If it hasn’t, it will engage DNS and go query both local and, if needed, external DNS servers until it gets an answer.

As an aside – because I can already hear some of you screaming at me about it – Windows systems may also employ something called NetBIOS name resolution. If – and that’s a really big two-letter word there – your system/network is configured to use NetBIOS name resolution, it will also look for matching names inside another plain-text file on your system: the lmhosts file. This works just like the HOSTs file, and can save a lot of time looking up name resolution if configured properly. Assuming it doesn’t find a match in lmhosts, the system can employ WINS and go look up a name there.

Note

Not only can you change the order in which your system resolves host name (a process that differs across operating systems and versions), you can manually edit both lmhosts and HOSTs. If you have local access to the machine, you can redirect any name to any IP address by simply typing the information into the file.

Regardless how the system does it – via a file manually updated on the system, a cache, or perhaps even DNS or WINS – eventually it will find an IP address that belongs to the URL Joe typed. With that knowledge, the system next builds a packet for delivery. This packet is built inside out and consists of the original data request, the TCP header [SYN], and the IP packet information affixed just before it. Once the bits are all in the correct order to build the packet, it is “handed down” to the Network Access layer for delivery.

Warning

You really need to know subnetting, which is mentioned in passing here but is fully covered in Chapter X. You’ll see anywhere from two to five questions per exam on it.

Joe’s computer must now find an address on its local subnet in order to deliver the packet. See, computers don’t communicate directly with anything outside their own network (subnet). If you think about it, this makes sense; it would be impossible for Joe’s computer to be hooked directly to every other endpoint in the world. Therefore, every single message must be delivered inside the subnet of which the system is a part. Each and every computer in the world is only concerned with, and capable of, sending a message to a machine inside its own subnet, so Joe’s system must find a local address that can deliver the packet to the IP address it has gathered.

Joe’s computer already knows its own physical address, but it has no idea of the answering system’s physical address, which could be anywhere. It knows the IP address of the destination device—thanks to DNS—but not the local, physical address. To gain that, Joe’s computer employs yet another protocol, Address Resolution Protocol (ARP).

ARP is a wonderful little protocol that basically yells a lot on a network. Its sole purpose in life is to let every system know where every other system in the network sits. To visualize this, imagine you’re in a big hallway with lots of doors. You know that various people sit behind these doors, and that your friend Fry is among them, but you don’t know where Fry sits. Instead of walking down the hall and knocking on each door, you just yell, “Hey! Where is Fry?” Everyone hears it, but only Fry sticks his head out the door and yells back, “I’m right here in room 3!” You (and everyone else in the hall) now know where Fry sits. ARP works the exact same way, just in a virtual sense, using Media Access Control (MAC) addresses (also known as physical addresses, as they are unique identifiers hard-coded on to each and every network interface card).

In our example, Joe is asking for a resource that is not in our local network (the IP address we resolved earlier doesn’t match our own subnet). Thus, when Joe’s system starts yelling with ARP, his subnet’s router will respond, “Send it to me, I can deliver that for you.” Once the system has the physical (MAC) address for the gateway (another groovy name for your local router port), it can then build the frame and send it out to the network. (For you network purists out there screaming “ARP isn’t needed for networks that the host already knows should be sent to the default gateway,” calm down—it’s just an introductory paragraph.)

This process of asking for a local address to which to forward the frame is repeated at every link in the network chain. Every time a router receives the frame along the way, it strips off the frame header and trailer and rebuilds the frame based on new ARP answers for that network chain. Finally, when the frame is received by the destination system, it will keeps stripping off and handing up the bit, frame, packet, segment, and data PDUs. This should result—if everything has worked right—in returning a SYN/ACK message to get things going.

Note

This introductory section covers only TCP. UDP—the connectionless, fire-and-forget transport protocol—has its own segment structure (called a datagram) and purpose. There are not as many steps with best-effort delivery, but you’ll find UDP just as important and valuable to your knowledge base as TCP.

To see this in action, take a quick look at Figure 1-4, which shows the frames at each link in the chain from Joe’s computer to a destination server. Note that the frame is ripped off and replaced by a new one to deliver the message within the new network; the source and destination MAC addresses change, but IPs never do.

Figure 1-4. Ethernet frames in transit

Although I’ve left out tons of stuff—such as port and sequence numbers, which will be of great importance to you later—this little journey touches on all the basics of TCP/IP networking. I’ll be covering it over and over again, and in more detail, throughout this book, so don’t panic if it’s not all registering with you yet.

One final thing I should add here before moving on, however, is the concept of network security zones. The idea behind this is that you can divide your networks in such a way that you have the opportunity to manage systems with specific security actions to help control inbound and outbound traffic. You’ve probably heard of these before, but I’d be remiss if I didn’t add them here:

Internet 

Outside the boundary and uncontrolled. You don’t apply security policies to the Internet. Governments try to all the time, but your organization can’t.

Internet DMZ 

Demilitarized zone (DMZ) refers to a section of land between two adversarial parties where there are no weapons or fighting. The idea is that you can see an adversary coming across the DMZ and have time to work up a defense. In networking, the idea is the same: it’s a controlled buffer network between you and the uncontrolled chaos of the Internet.

Production Network Zone 

A very restricted zone that strictly controls direct access from uncontrolled zones. The PNZ doesn’t hold users.

Intranet Zone 

A controlled zone that has few to no heavy restrictions. This is not to say everything is wide open, but communication requires fewer strict controls internally.

Management Network Zone 

A highly secured zone with very strict policies. Usually rife with Virtual LANs (VLANs) and maybe controlled via IPSec and such. This is a highly secured zone with very strict policies.

Note

DMZs aren’t just buffers between the Internet and a network; they can be inside or outside various internets and intranets, anywhere an organization decides it wants or needs a buffer. DMZ networks provide great opportunities for security measures, but can also sometimes become an Achilles’ heel when too much trust is put into their creation and maintenance.

Vulnerabilities

In our romp through “things you’re already supposed to know,” we need to spend a few moments on vulnerabilities. A vulnerability is a weakness that an attacker can exploit to perform unauthorized actions within a computer or network system. Since our job as security professionals and pen testers is to keep our systems safe and point out the weaknesses in security design, we should all know vulnerability management well and do our best at keeping vulnerabilities to a minimum.

So how can you know what vulnerabilities are out there and what dangers they might pose? And is there a ranking system to determine which vulnerabilities are more dangerous than others? Glad you asked.

First, if you’re looking for lists of vulnerabilities and resources on them, try a few of the following links to get you started (there are plenty others; these are just a few of the ones available):

• Microsoft Vulnerability Research

• Security Focus

• Hackerstorm

• Exploit Database

• Security Magazine

• Trend Micro

• Dark Reading

• Computerworld

It’s one thing to know what vulnerabilities exist, but it should follow that knowing what actual risk each poses – how to quantify the danger or risk of each particular vulnerability – would be an important piece of information in order to plan your security resources appropriately. The (CVSS) is a universally adopted method for doing just that. CVSS describes itself as an

open framework for communicating the characteristics and severity of software vulnerabilities. CVSS consists of three metric groups: Base, Temporal, and Environmental. The Base metrics produce a score ranging from 0 to 10, which can then be modified by scoring the Temporal and Environmental metrics. A CVSS score is also represented as a vector string, a compressed textual representation of the values used to derive the score. The numerical score of a given vulnerability can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.

It’s also helpful to have a quick and ready means of listing and searching for what you want. The Common Vulnerabilities and Exposures (CVE) system, launched in 1999, is a relatively easy-to-use, free public reference that provides full lists of all known vulnerabilities (and, often, exposures), along with search options and other information. It’s maintained by the National Cybersecurity FFRDC, operated by the MITRE Corporation, and funded by the National Cyber Security Division of the United States Department of Homeland Security. The system was officially launched for the public in September 1999, and provides full lists of all known vulnerabilities, as well as search options and other information.

CVE ties into the National Vulnerability Database (NVD), which describes itself as the “U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance.” It provides information on vulnerabilities, metrics, dictionaries, reference materials, and even configuration guides to help you protect specific systems against specific threats.

Note

Another vulnerability-related site you may see from time to time is Common Weakness Enumeration (CWE), self-described as “a community-developed list of software and hardware weakness types. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts.”

As a pen tester, you need to remain as up to date as possible on active vulnerabilities (knowledge of new ones pops up all the time).

Exactly what are you expected to do about a vulnerability? Just because a vulnerability exists doesn’t necessarily mean your system is at huge risk. For example, my computer, sitting right here in my home office, is vulnerable to bear attack: there is literally no way it could survive a mauling by a grizzly bear. But what are the odds of a bear coming through my front door and, maybe enraged by the red LED stripes across the front and back, attacking my system? And what are the odds that, even if the bear came into the house, I wouldn’t blast it with my .357 Magnum sidearm, preventing the attack in the first place?

Sure, it’s a ridiculous example, but it proves a point: vulnerabilities are always present on every system. Your job as a security professional is to put in place as many security controls as realistically possible to prevent anyone from exploiting them. Vulnerability and risk assessments are designed specifically to look at the likelihood that potential vulnerabilities on your system will actually be exploited. How hard would it be to exploit the vulnerability? Is it even possible for an attacker given the security controls put into place?

While we’re on that subject, what are those security controls, and how do they work in preventing access or exploitation? Auditors and security folks deal with these questions on a daily basis. To answer them, start with a solid baseline of your system—a full and complete inventory of what you have and what those systems are vulnerable to—then plan and act accordingly.

Warning

Vulnerability assessments fall into many different types. An assessment looking for wireless vulnerabilities? That would be a Wireless Assessment. One using credentials? It’s a Credentialed Assessment. Automated effort using a tool versus a manual look? That’d be an Automated Assessment versus a Manual Assessment. Just use common sense here.

EC Council lists four main approaches to vulnerability assessments. Product-based solutions are it’s owned and operated by, and installed within, the organization, on private IP space. It doesn’t run outside and, therefore, cannot always detect outside issues. A service-based solution is one owned and operated by a third party on behalf of the organization. While portions may be installed inside the organization network, it is accessible from the outside. One drawback is that an attacker may be able to audit the organization externally. In a tree-based assessment approach, the administrator selects different tactics for each machine, OS, or component in the network. This relies on the administrator providing the up-front intelligence correctly and then scanning as instructed. Finally, with an inference-based approach, you build a port and protocol map of each device, then select vulnerability tests and actions accordingly. The official courseware doesn’t give preference to any one approach.

Note

A few of the vulnerability management tools listed and defined by ECC include Nessus, Qualys, GFI Languard, Nikto, OpenVAS, and Retina CS.

Security Basics

If there were a subtitle to this section, I would have called it “Ceaseless Definition Terms Necessary for Only a Few Questions on the Exam.” There are tons of these, and I gave serious thought to skipping them all and just leaving you to a glossary. However, because I’m in a good mood and, you know, I promised my publisher I’d cover everything, I’ll give it a shot here. And, at least for some of these, I’ll try to do so using contextual clues in a story.

Bob and Joe used to be friends in college, but had a falling out over doughnuts. Bob insisted Krispy Kremes were better, but Joe was a Dunkin’ fan, and after much yelling and tossing of fried dough they became mortal enemies. After graduation they went their separate ways. Eventually Bob became Security Guy Bob, in charge of security for Orca Pig (OP) Industries, Inc., while Joe made some bad choices and went on to become Hacker Joe.

At OP, Bob noticed that most decisions favored usability over functionality and security. He showed upper management a Security, Functionality, and Usability triangle (see Figure 1-5), visually displaying that moving toward one of these three would lessen the other two and weaken security in the long term. Management noted Bob’s concerns and summarily dismissed them as irrational, as budgets were tight and business was good.

Figure 1-5. The Security, Functionality, and Usability triangle

A few weeks after Bob started his new job, Hacker Joe woke up and decided he wanted to be naughty. He went out searching for a target of hack value, so he wouldn’t waste time on something that didn’t matter. He found OP, Inc., and smiled when he saw Bob’s face on the company directory. He searched and found a target, researching to see if it had any weaknesses, such as software flaws or logic design errors. A particular vulnerability did show up on the target, so Joe researched attack vectors and discovered—through his super-secret hacking background contacts—a potential attack on some software on the target system. The software’s developer apparently didn’t even know about since they hadn’t released any kind of security patch or fix to address the problem. This zero-day attack vector required a specific piece of exploit code Joe could inject through a hacking tactic he thought would work. Joe obfuscated this payload, embedded it in an attack, and got started.

After pulling off the successful exploit and owning the box, Joe explored what additional access the machine could grant him. He discovered other targets and vulnerabilities and successfully configured access to them all. By daisy-chaining network access, Joe gave himself the option to set up several machines on multiple networks, which he could control remotely at any time. He could use these bots execute whatever he wanted.

Since these bots could be accessed any time he wanted, Joe decided to prep for more carnage. He searched publicly available databases and social media for personally identifiable information (PII) about Bob, then posted his findings. After this doxing effort, Joe took a nap, dreaming about the embarrassment that would rain down on Bob the next day.

Warning

Another fantastic bit of ECC terminology is threat modeling. It’s exactly what it sounds like and consists of five sections: Identify Security Objectives, Application Overview, Decompose Application, Identify Threats, and Identify Vulnerabilities.

After discovering PII posts about himself, Bob worried that something was amiss, and if his old nemesis was back and on the attack. He did some digging and discovered Joe’s attack from the previous evening. Bob immediately engaged his incident response team (IRT) to identify, analyze, prioritize, and resolve the incident. The team reviewed detection quickly analyzed the exploit, and notified the appropriate stakeholders. Then they worked to contain the exploit, eradicate residual back doors, and recover lost data and services. After this incident management process, the team provided management with a post-incident report summing up the lessons they’d learned.

Note

Here’s a great three-dollar term you might see on the exam: An organization’s enterprise information security architecture (EISA) is a collection of requirements and processes that help determine how its information systems are built and how they work.

In their report, the team suggested to leadership that they focus more attention on security, proposing to identify what risks were present and quantify them on a measurement scale. This risk management approach would allow them to come up with solutions to mitigate, eliminate, or accept the risks they identified (see Figure 1-6 for a sample risk analysis matrix).

Figure 1-6. Risk analysis matrix

Identifying the organization’s assets, the threats to those assets, and the system’s vulnerabilities would allow the company to explore countermeasures. Some of these security controls would prevent errors or incidents from occurring in the first place; some were to identify that an incident had occurred or was in progress; some were designed for after the event, to limit the extent of the damage and aid swift recovery. These preventative, detective, and corrective controls would work together to increase OP’s system’s security posture, minimize risks as much as possible, and reduce Joe’s ability to further his side of the great Doughnut Fallout.

Note

Security controls can be categorized as physical, technical, or administrative. Physical controls include things like guards, lights, and cameras. Technical controls include encryption, smartcards, and access-control lists. Administrative controls include training, awareness, and policy efforts. The latter are usually well intentioned, comprehensive, and well thought out—and most employees ignore them. Hackers will combat physical and technical controls to get to their end goal, but they don’t give a rip about your administrative password policy—unless everyone actually follows it.

This effort spurred a greater focus on overall preparation and security. Bob’s quick action had averted what could have been a total disaster, but everyone involved, including management, saw the need for better planning and preparation. They kicked off an effort to identify the most critical systems and processes for operations. This business impact analysis (BIA) included measurements of the maximum tolerable downtime (MTD), which would help them prioritize asset recovery should the worst occur. Bob also branched out and created Orca Pig’s first set of disaster plans and procedures to to get business services back up and running—whether the failure was security-related or not. His business continuity plan (BCP) included a disaster recovery plan (DRP), addressing exactly what to do to recover any lost data or services.

Bob also did some research his management should have, and discovered some additional actions and groovy acronyms they should know and pay attention to. When putting assigned numbers and values to his systems and services, the annualized loss expectancy (ALE) was the product of the annual rate of occurrence (ARO) and the single loss expectancy (SLE).

For his first effort, he looked at one system and determined its worth, including the cost for returning it to service and any lost revenue during downtime, to be $120,000. Bob made an educated guess on the percentage of loss for this asset if a specific threat was actually realized. He determined the exposure factor (EF) to be 25 percent. He multiplied this by the asset value and came up with an SLE of $30,000 ($120,000 × 25%).

Next, Bob wanted to figure out the probability that this would occur in any particular 12-month period. Given the statistics he’d garnered from similarly protected businesses, he thought it could occur once every five years, which gave him an ARO of 0.2 (1 occurrence / 5 years). By multiplying the estimate of a single loss versus the number of times it was likely to occur in a year, Bob generated the ALE for this asset: $6,000 ($30,000 × 0.2). Repeating this process across Orca Pig’s assets provided valuable information for planning, preparation, and budgeting.

Warning

ALE = SLE × ARO. Know it.

At the end of this weeklong effort, Bob relaxed with a Maker’s Mark and an Arturo Fuente cigar on his back porch, smiling at the thought of all the good security work he’d done and the bonus he’d been rewarded. Meanwhile, Joe stewed in his apartment, angry that his work would now be exponentially harder. But while Bob took the evening to rest on his laurels, Joe went back to work, scratching and digging at OP’s defenses. “One day I’ll find a way in,” he vowed. “Just wait and see. I won’t stop. Ever.”

Now, wasn’t that better than just reading definitions? Sure, there were a few leaps, and Bob surely wouldn’t be the one doing ALE measurements, but it was better than trying to explain all that otherwise. Every italicized word in this section could possibly show up on your exam, and now you can just remember this little story and you’ll be ready for almost anything. But although this was fun, and I did consider continuing the story throughout the remainder of this book (fiction is so much more entertaining), some of these topics need a little more than a passing reference (which the rest of this book will tackle), so we’ll break here and go back to more “expected” writing.

CIA

Another bedrock in any security basics discussion is the holy trinity of IT security: confidentiality, integrity, and availability (known as the CIA triad). Whether you’re an ethical hacker or not, these three items constitute the hallmarks of security. You’ll need to be familiar with two aspects of each term: its meaning and which attacks are most commonly associated with it.

Confidentiality, which addresses the secrecy and privacy of information, refers to measures to prevent disclosure of information or data to unauthorized individuals or systems and to ensure the proper disclosure of information to those who are authorized to receive it. For individuals, losing confidentiality could result in identity theft, fraud, and loss of money. For a business or government agency, it could be even worse. A user ID/password combination is by far the most common measure taken to ensure confidentiality, and attacks against passwords are, amazingly enough, the most common confidentiality attacks. However, numerous other options are available, including biometrics and smartcards.

For example, when you log in to a network, you usually do so with a user ID and a password, which is designed to ensure that only you have access to that particular device or set of network resources. If another person were to gain your user ID and password, they would have unauthorized access to resources and could masquerade as you throughout their session. Although the user ID and password combination is by far the most common method used to enforce confidentiality, numerous other options are available, including biometrics and smartcards.

Warning

Be careful with the terms confidentiality and authentication. Sometimes these two are used interchangeably, and if you’re looking for only one, you may miss the question altogether. For example, a MAC address spoof (using the MAC address of another machine) is considered an authentication attack. Authentication is definitely a major portion of the confidentiality segment of IT security.

Integrity refers to methods and actions to protect information from unauthorized alteration or revision—whether the data is at rest or in transit. In other words, integrity measures ensure the data sent from the sender arrives at the recipient with no alteration. For example, imagine a buying agent sending an e-mail to a customer offering a price of $300. If an attacker somehow alters the e-mail and changes the offering price to $3,000, the integrity measures have failed and the transaction will not occur as intended, if at all. Often, attacks on the integrity of information are designed to cause embarrassment or legitimate damage to the target.

Integrity in information systems is often ensured using a hash function: a one-way mathematical algorithm (such as MD5 or SHA-1) that generates a specific, fixed-length number (known as a hash value). Within any system containing integrity controls, when a user or system sends a message, a hash value is also generated to send to the recipient. If even a single bit is changed during the transmission of the message, instead of showing the same output, the hash function will calculate and display a greatly different hash value on the recipient’s system. Depending on the way the controls within the system are designed, either the message will be retransmitted or the session will completely shut down.

Availability is probably the simplest, easiest-to-understand segment of the security triad, yet it should not be overlooked. It refers to communications systems and data being ready for use when legitimate users need them. Many methods are used to ensure availability, depending on whether the discussion is about a system, a network resource, or the data itself, but they all attempt to ensure one thing—when the system or data is needed, it can be accessed by the appropriate personnel.

Attacks against availability almost always fall into the “denial-of-service” realm. Denial-of-service (DoS) attacks are designed to prevent legitimate users from having access to a computer resource or service and can take many forms. For example, attackers could attempt to use all available bandwidth to the network resource, or actively attempt to destroy a user’s authentication method. DoS attacks can also be much simpler than that—unplugging the power cord is the easiest DoS in history!

Note

Many in the security field add other terms to the security triad. I’ve seen several study guides refer to the term authenticity as one of the “four elements of security.” It’s not used much outside the certification realm, however; the term is most often used to describe something as “genuine.” For example, digital signatures can be used to guarantee the authenticity of the person sending a message. Come test time, this may help.

Risk and Risk Management

If I asked you if you knew what the term risk meant, you’d probably immediately say yes. It seems intuitive; however, getting an exact definition can be tricky – especially when we’re talking about certification exams. I’ve seen many definitions of risk in many different publications, but I think my best effort here would be something like this: risk refers to a specific level of uncertainty regarding a potential event that could cause damage to your organization’s assets, availability, or reputation. Yeah, I know, that’s a mouthful. Let’s dive in.

Risk management is all about determining what ‘level’ or ‘degree’ you’d like to assign to any potential event that causes damage to your organization. In other words, you attempt to categorize specific risks into levels according to their potential impact on your system. Suppose, for example, you were rating the risk of 747 jets plummeting out of the sky directly into your data center. You’d need to take into account the likelihood it would happen (next to never), and the impact it would have should it actually occur (pretty catastrophic). You’d then plot this out using a risk matrix, assign it a level or degree (in this instance, you might even rate this one a ‘high’), and then discuss what measures you could take to reduce the impact and/or likelihood of this event occurring.

As you can gather from our obviously hyperbolic example here, risk management is somewhat subjective and there’s a lot of argument and disagreement along the way to resolution. That’s exactly why you need a good risk management process: to ensure system security is paramount, not just subject to the opinions of everyone in the room. Generally speaking, risk management has five main phases: Risk Identification, Risk Assessment, Risk Treatment, Risk Tracking, and Risk Review. This process never ends and is constantly expanding, yet it’s at the absolute core of your security efforts.

Incidents

I don’t like being the bearer of bad news, but sooner or later, you’re going to lose. The bad guys have time on their side. While we have to be perfect, on our top game every day, without fail, and always right, the bad guys just have to be right or lucky once. This near-inevitability can be depressing to think about, but you should spend some time planning how you will respond to an incident.

For starters, a plan of approach would be a good idea. Your incident management process will identify, prioritize, analyze, and (hopefully) resolve the incident within a reasonable timeframe. Your goal here is to lay out the processes, people, resources, and analytics necessary to bring things back to normal operations as quickly and fully as possible.

Within your overall incident-management processes, incident response (IR) will play a key role. Generally speaking, IR has five main steps: Identify, Contain, Eradicate, Restore, and Document (lessons learned). Your CEH study has included four other steps steps you may need to pay attention to, brining their total to nine steps in IR: Preparation, Recording and Assignment, Triage, Notification, Containment, Evidence Gathering, Eradication, Recovery, Post-incident activity. Regardless whether you’re studying for an exam and have nine steps, or you’re actually in the field and your organization stick with five, it’s critical you have a plan, and you stick to it.

Methodologies and Frameworks

Some of my favorite memories as a child are of my father putting together toys, furniture, bikes, and so on. “Some assembly required” became almost curse words in our family, as Dad would often fall into a rage trying to figure out how to put the thing together. The manufacturers always included an instruction sheet, mind you, but gems like “Place bolt B in slot X while holding panel 2 and 4 together” made Dad’s eye start twitching. So he often ignored the instruction sheet and, inevitably, we’d wind up with extra parts. Sometimes those extra parts didn’t matter, and sometimes we had to disassemble the whole thing and start over.

In our waltz through various terms and definitions, the instruction manuals we use in ethical hacking can be called methodologies or frameworks. The idea isn’t that you have to step through an attack by rote, making sure you check the box for phase 1 before moving to phase 3. Instead, the point is to ensure you don’t miss anything – that you don’t wind up with virtual “extra parts” that could’ve been key to a successful attack. In this section we’ll look at EC Council’s hacking phases and a couple of real-world frameworks for thinking about attacks.

Hacking Phases

Regardless of the intent of the attacker (remember, there are good guys and bad guys), hacking and attacking systems can sometimes be akin to a pilot flying her plane. That’s right, I said “her.” My daughter is a helicopter pilot for the U.S. Air Force, and because of this ultra-cool access, I get to talk with pilots from time to time. I often hear them say, when describing a mission or event, that they just “felt” the plane or helicopter—that they just knew how it was feeling and the best thing to do to accomplish the goal, sometimes without even thinking about it.

When I asked my daughter about this human–machine relationship, she paused for a moment and told me that sure, it exists, and it’s uncanny to think about why pilot A did action B in a split-second decision. However, she cautioned, all that mystical stuff can never happen without all the up-front training, time, and procedures. Because the pilots follow a procedure and take their time up front, the decision making and “feel” of the machine can come to fruition.

The CEH Hacking Methodology (CHM) defines five main phases of an attack, with a couple subphases sprinkled within. For you, my hacking pilot trainee, these phases are a great way to think about an attack structure. However, I’m not saying you shouldn’t take advantage of opportunities when they present themselves, just because they’re out of order. (If a machine presents itself willingly and you refuse the attack, exclaiming, “But I haven’t reconned it yet!” I may have to slap you myself!) In general, though, following the plan will produce quality results. There are many different terms for these phases, and some of them run concurrently and continuously throughout a test. For the exam, you’ll need some idea of what happens in each of them.

Warning

As we go through these steps, you’ll probably start yelling at the page, “HEY! That’s part of phase three, not phase two!” Trust me, I understand. Just know that there’s plenty of bleed-over and gray areas between one phase and the next. When faced with a definition decision on your exam, pay close attention to the exact wording of the question. Usually it’ll help you by defining the previous or next phase.

Phase 1: Footprinting

In earlier CEH versions, the first phase was listed as reconnaissance, but in the current version, the first step in the CHM is footprinting. On the exam, this phase can be one of the most difficult to understand, mainly because many people confuse some of its steps as being part of the next phase, scanning (including enumeration).

Footprinting is nothing more than the steps taken to gather evidence and information on the targets you want to attack. It can be passive or active in nature: passive footprinting gathers information without any direct interaction on the part of the attacker, whereas active footprinting does require direct interaction. We’ll get more into this further ahead in the next chapter.

Phase 2 and 3: Scanning and Enumeration

The second phase, scanning, begins a true divergence between real world and exam, and if you’ll permit me a slight moment here, I’ll explain. See, scanning in the real world generally means simply identifying networks and hosts – basically making a big list of what’s live on the network. EC Council takes this a little bit further and adds discovering the target system’s operating system, architecture, running services, and vulnerabilities as steps taken in scanning. This may become horribly confusing to you as enumeration (the next phase) is the term most folks apply to fingerprinting an operating system.

So how do you determine whether you’re in scanning or enumeration, come exam time? Pay close attention to the wording. Enumeration implies an active effort on the part of the attacker, not just passively watching traffic as, potentially, in scanning. Enumeration involves creating active connections to the target, and preforming directed queries within that connection. As an extra aside, the official study material calls out enumeration as occurring within the ‘intranet’ environment. Intranet is a term defining traffic inside your subnet (extranet meaning outside). Therefore, if you’re on the exam and trying to figure out what phase the discovery of vulnerabilities on the system sits in, try to examine the question to see where the information is being gathered from. If it’s an intranet effort, you’re in enumeration. If extranet, you’re just scanning. In either case, the methodology step you’re working in is defined as Scanning. See? Clear as a muddy river…

Scanning can be something as simple as running a ping sweep or a network mapper to see what systems are on the network, while enumeration may use a vulnerability scanner to determine which ports may be open on a particular system. For example, whereas the first phase may have shown the network to have 500 or so machines connected to a single subnet inside a building, scanning and enumeration would tell you which ones are Windows machines and which ones are running FTP.

Phase 4: Vulnerability Analysis

In the fourth phase, vulnerability analysis, security professionals really get to work. After we’ve footprinted, scanned and enumerated our target(s), we now spend some time evaluating the potential vulnerabilities on the system(s). For example, if it’s physical security we’re talking about, maybe we research the cameras, locks, guard-company hiring practices, and so on to see what weaknesses we can find. If it’s the system itself, we would check for misconfigurations and vulnerability scans, prioritizing each vulnerability and hopefully sifting through any false positives. In any case, this is the time we spend digging into potential vulnerabilities we find, and getting them lined up in a report so we can take action.

Phase 5: System hacking

Speaking of action, the fifth phase, system hacking, is where the magic happens. This is the phase most people delightedly rub their hands together over, reveling in the glee they know they will receive from bypassing a security control. It contains four subphases:

Gaining access

In gaining access, true attacks (like password cracking and vulnerability exploitation) are leveled against the target. These attacks can be as simple as accessing an open and unsecured wireless access point and manipulating it for whatever purpose, or as complex as writing and delivering a buffer overflow or SQL injection against a web application. The attacks and techniques used in the phase will be discussed throughout the remainder of this text.

Escalation of privileges

Here, the attacker takes steps to increase the access and privileges they have. In other words, it’s one thing to gain access, but it’s another altogether to leverage that access to change a password or delete files. The attacker must somehow gain higher privilege (administrator, root, superuser) in order to really get into the weeds.

Maintaining access

In the next subphase, maintaining access, the attacker attempts to ensure they have a way back into the machine or system they’ve already compromised. They leave back doors open for future use, especially if they’ve turned the system in question into a zombie (a machine used as a launching point for further attacks) or used it for further information gathering—for example, placing a sniffer on a compromised machine to watch traffic on a specific subnet. Access can be maintained using Trojans, rootkits, or any number of other methods.

Note

There’s an important distinction I’ve mentioned before and will mention over and over again through this book: ECC and study materials for the CEH often have as much to do with the real world and true hacking as nuclear fusion has to do with doughnut glaze. For example, in the real world, pen testers and hackers only carry out scanning and enumeration when the possibility of gaining useful intelligence is greater than the risk of detection or reaction by the target. Sure, you need as much information as you can get up front, but if what you’re doing winds up drawing unnecessary attention to yourself, the whole thing is pointless. Same thing goes for privilege escalation: if you can get the job done without bothering to escalate to root privilege, huzzah!

Clearing logs

In the final subphase of system hacking, clearing logs, the attacker attempts to conceal their success and avoid detection by removing or altering log files, hiding files with hidden attributes or directories, or even using tunneling protocols to communicate with the system. If auditing is turned on and monitored (and often it is not), log files may indicate attacks on a machine. Clearing the log file completely is just as big an indicator to the security administrator watching the machine, so sometimes selective editing is your best bet.

Another great method to use here is simply corrupting the log file itself. Whereas a completely empty log file screams that an attack is in progress, files get corrupted all the time. Chances are, the administrator won’t bother trying to rebuild the log file. In either case, be really careful when it comes to corrupting or deleting logs in the real world. As a pen tester, you may be bound by a “no harm” clause, which will prevent you from altering the log files at all. Not only would that cause harm to the organization, but it could also prevent it from discovering real bad guys who may be attacking during your test. Good pen testers are truly defined in this phase, and “do no harm” should be in the forefront of your mind when attempting this.

Warning

An acronym you should definitely get acquainted with is SIEM: security incident and event management. A SIEM helps to perform functions related to a Security Operation Center (SOC), such as identifying, monitoring, recording, auditing, and analyzing security incidents. While the term can be associated with an overall enterprise effort (made up of people, applications, processes, and so on), in the real world oftentimes it is used to refer to a specific application. Splunk, for example, is often referred to as a SIEM platform.

A couple of insights can, and should, be gained here. First, contrary to popular belief, pen testers do not usually just randomly assault things hoping to find some overlooked vulnerability to exploit. Instead, they follow a specific, organized method to thoroughly discover every aspect of the system they’re targeting. Good ethical hackers performing pen tests ensure these steps are very well documented, taking exceptional and detailed notes and keeping items such as screenshots and log files for inclusion in the final report. A great friend of mine and an indisputable expert in this field, Mr. Brad Horton, put it this way: “Pen testers are thorough in their work for the customer. Hackers just discover what is necessary to accomplish their goal.” Second, keep in mind that security professionals performing a pen test do not normally repair or patch any security vulnerabilities they find—it’s simply not their job to do so. The ethical hacker’s job is to discover security flaws for the customer, not to fix them. Knowing how to blow up a bridge doesn’t make you a civil engineer capable of building one, so while your friendly neighborhood CEH may be able to find your problems, it in no way guarantees he or she could engineer a secure system.

Note

A hacker who is after someone in particular may not bother sticking to a set method in getting to what is wanted. Hackers in the real world will take advantage of the easiest, quickest, simplest path to the end goal, and if that means attacking before enumerating, then so be it.

The Cyber Kill Chain

In our romp through terminology and methodology, we need to spend a few moments on a relatively new entry to the study lexicon: the Cyber Kill Chain methodology. The idea behind this is very simple, and mirrors what you, dear reader, are trying to do yourself: think like the bad guy. Its developer, Lockheed Martin, describes this framework as “part of the Intelligence Driven Defense® model for identification and prevention of cyber intrusions activity. The model identifies what the adversaries must complete in order to achieve their objective.” Knowing the steps adversaries need to take tells you what they might be thinking, which can help in setting a security response.

The Cyber Kill Chain methodology consists of seven phases, which are set out in Table 1-1.

Table 1-1. Lockheed Martin’s Cyber Kill Chain

Phase	Details
1 - Reconnaissance	Gathering data and information on a target, identifying vulnerabilities, and establishing an attack platform
2- Weaponization	Creating some sort of malicious payload for delivery to the target, using the vulnerabilities, back doors, and/or exploits discovered in step 1.
3- Delivery	Sending the payload to the target, through any of a variety of means
4- Exploitation	Executing the delivered code on the target system
5- Installation	Installing the malicious application on the target
6- Command and Control (C&C)	Creating a C&C channel to send data back and forth to the target
7- Actions on Objectives	Perform actions to complete the mission. In effect, this is where you carry out the activities you need to steal or malform data, set up a bot machine, pivot to a new system, or whatever your initial intent was.

Note

Another term used in this realm is adversary behavioral identification, which refers to identifying a particular attacker’s common methods; like their unique way of using Powershell or the command line interface. Perhaps your attacker is fond of DNS tunneling, or using a web shell or proxies, or [insert tactic here]. Building a profile isn’t just for the detectives on TV. Now it’s your job, too.

As an aside, the idea behind thinking like the bad guy is to help anticipate what they’d go after, how they might do that, and even when they might. Just as FBI profilers do with serial murderers and bomb experts do with the fragments recovered at a scene, we can do a better job of anticipating the bad guys by noting specific patterns of behavior, activities and methods they use. Each person is different, after all, and repeating the steps you already know provides a fingerprint of sorts to an attacker’s hacking naughtiness. These fingerprints, these patterns of action, are known as Tactics, Techniques and Procedures, or TTPs.

Warning

The difference between a tactic and a technique is vague, at best. The best I can find is a tactic is a ‘way’, while the technique is the ‘technical method’ used. The official courseware itself doesn’t seem to know the difference between the two, so just use best judgement on the exam should you see it.

Another term you’ll definitely come across is indicator of compromise (IOC). IOCs are basically clues that you’ve been hacked – identifiers, tidbits of information or settings, etc. There are four main types of IOCs:

Email Indicators

Items such as specific senders’ addresses, subject lines, and types of attachments

Network Indicators

These include URLs, domain names, and IP addresses

Host -Based Indicators

Items such as specific filenames, hashes, and registry keys

Behavioral Indicators

Specific behaviors that indicate an ongoing attack, such as powershell executions and remote command executions

Warning

Email, network, and host-based indicators, as defined by EC Council, seem to be more… tangible… in nature than behavioral ones. For example, network traffic at 02:00 every day for a week might be an indicator of compromise, but could fall more into the realm of behavior than of networks. Just stick with the definitions listed here and you should be fine.

MITRE ATT&CK Framework

Imagine there was a non-profit organization focused on providing technical guidance to the Federal government that became a source for security professionals around the world. Imagine this non-profit decided along the way to help security professionals everywhere by leveraging their immense knowledge base and access to information. Imagine they put their resources together in an organized knowledge base that could be easily used to track malicious tactics and techniques across an entire attack lifecycle. And imagine it was all made available to security professionals for free. Well, imagine no more – this is real.

MITRE is, indeed, that non-profit organization, and their free-to-use framework for tracking tactics and techniques during an attack is called the ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) framework. MITRE describes ATT&CK as a “knowledge base of adversarial techniques based on real-world observations” that “focuses on how adversaries interact with systems during an operation, reflecting the various phases of an adversary’s attack lifecycle and the platforms they are known to target. It is a model that attempts to systematically categorize adversary behavior.”

ATT&CK catalogues information from thousands of sources. Not only does it identify types of attacks and general functions, it even correlates specific actors and malicious groups with active campaigns. Since specific actors tend to use the same techniques, the ATT&CK framework can help you prepare for and respond to a specific threat. You can access this yourself any time and manually scroll around to dive into specific information, or make use of any number of tools to see exactly what the malicious actor is up to or to plan for better security.

Note

EC Council’s study materials give only a passing glance to MITRE ATT&CK in their study material – hence I don’t spend an inordinate amount of time on it here – but I highly advise you to go check it out and learn how to use it. Scroll around to dive into specific information, or use the tools to see exactly what a malicious actor is up to or plan for better security.

The ATT&CK framework is designed around four main components across three technology domains. The four main components of the framework are:

Tactics

“Why,” or the reason an adversary is performing an action

Techniques

“How” adversaries achieve tactical goals by performing actions

Subtechniques

More specific or lower-level descriptions of adversarial behavior

Procedures

Specific implementations or in-the-wild uses for techniques or subtechniques.

The three technology domains in the framework are enterprise, representing traditional enterprise networks and cloud technologies; mobile, for mobile communication devices; and ICS, for industrial control systems.

Diamond Model of Intrusion Analysis

Finally, there’s the latest entry into the dance: the Diamond Model. In a 2013 report to the US Department of Defense, Sergio Caltagirone, Andrew Pendergast, and Christopher Betz proposed that

For every intrusion event, there exists an adversary taking a step toward an intended goal by using a capability over infrastructure against a victim to produce a result. This means that an intrusion event is defined as how the attacker demonstrates and uses certain capabilities and techniques over infrastructure against a target.

Thus the Diamond Model of Intrusion Analysis was born. The framework revolves around four key components:

Adversary

“Who”: the individual or group responsible for the incident

Infrastructure

“What”: the resources (like IP addresses, domains, servers, etc.) used by the malicious actor during the attack

Capability

“How”: the strategies, methods, tools, or techniques used to perform the attack (such as malware, injection, etc.)

Victim

“Where”: the targeted individual or organization.

Warning

EC Council has something called the ‘Cybersecurity Exchange,’ where they share loads of information for free. Given this framework is in the official courseware and they have a long write up about it in their freely-accessible information exchange, I’d highly recommend you go read their exact wording on it.

Introduction to Ethical Hacking

Ask most people to define the term hacker, and they’ll instantly picture a darkened room, several monitors ablaze with green text scrolling across the screen, and a shady character in the corner furiously typing away on a keyboard in an effort to break or steal something. Unfortunately, there’s some truth to that image: and a lot of people worldwide actively participate in hacking activities for that very purpose. However, there are important differences between the good guys and the bad guys in this realm. This section defines the two groups and provides some background.

Hacking Terminology

Whether it’s done for noble or bad purposes, the art of hacking remains the same. Using a specialized set of tools, techniques, knowledge, and skills to bypass computer security measures allows someone to hack into a computer or network. The purpose behind their use of these tools and techniques is really the only thing in question. Whereas some use these tools and techniques for personal gain or profit, the good guys practice them in order to better defend their systems and, in the process, provide insight on how to catch the bad guys. As a matter of fact, that differentiation defines the ‘ethical’ hacker from the bad guys; the ethical hacker proceeds only with the permission of the target organization and operates with a written, agreed upon contract and rules of engagement before attempting any attacks.

Like any other career field, hacking (ethical hacking) has its own lingo and a myriad of terms to know. Hackers themselves, for instance, have various terms and classifications to fall into. For example, you may already know that a script kiddie is a person uneducated in hacking techniques who simply makes use of freely available (but often outdated) tools and techniques on the Internet. And you probably already know that a phreaker is someone who manipulates telecommunications systems in order to make free calls. But there may be a few terms you’re unfamiliar with that this section may be able to help with. Maybe you simply need a reference point for test study, or maybe this is all new to you; either way, perhaps there will be a nugget or two here to help on the exam. In an attempt to avoid turning this book into a dictionary, this section will stick with the more pertinent information you’ll need to remember. You’ll see these terms used throughout the book, and most of them are fairly easy to figure out, but don’t discount the definitions you’ll find in the glossary. (Besides, I worked really hard on the glossary—it would be a shame if it went unnoticed.) We’ll start with hackers themselves.

Warning

Don’t miss the easy ones! Definition questions should be no-brainers on the exam. Learn the hacker types, the stages of a hack, and other definitions.

Hacker Classifications: Hats and Types

You can categorize hackers in countless ways (EC Council gives us 13 terms to remember), but the “hat” system seems to have stood the test of time. I don’t know if that’s because hackers like Western movies or if we’re all just fascinated with cowboy fashion, but it’s definitely something you’ll see on your exam. The hat system uses colors to divide the hacking community into three separate classifications: the good, the bad, and the undecided.

White hats 

Considered the good guys, these are the ethical hackers, hired by a customer for the specific goal of testing and improving security or for other defensive purposes. White hats are well respected and don’t use their knowledge and skills without prior consent. White hats are also known as security analysts.

Black hats 

Considered the bad guys, these are the crackers, illegally using their skills for either personal gain or malicious intent. They seek to steal (copy) or destroy data and to deny access to resources and systems. Black hats do not ask for permission or consent.

Gray hats 

The hardest group to categorize, these hackers are neither good nor bad. Generally speaking, there are two subsets of gray hats—those who are simply curious about hacking tools and techniques, and those who feel like it’s their duty to demonstrate security flaws in systems-- with or without permission. In either case, hacking without explicit permission and direction is usually a crime.

Note

Some well-meaning hacker types have found employment in the security field by hacking into a system, finding a security flaw, and then informing the victim of the flaw so that they can fix it. Many, many more have found their way to prison attempting the same thing. Regardless of your intentions, do not practice hacking techniques without approval. You may think your hat is gray, but I guarantee the victim sees only black.

While we’re on the subject, another class of hacker borders on the insane. Some hackers are so driven, so intent on completing their task, they are willing to risk everything, even their safety or freedom (or those of others), to pull it off. Whereas we, as ethical hackers, won’t touch anything until we’re given express consent to do so, these hackers feel that their reason for hacking outweighs any potential punishment. Working with a scorched-earth mentality, so-called suicide hackers are the truly scary monsters in the closet.

The remaining nine types to commit to memory are:

Script kiddies

As noted above, these are unskilled folks who simply cut and paste readily available tools and scripts to carry out attacks.

Cyber terrorists

These attackers are motivated by religious or political beliefs to carry out attacks with the intent of causing fear.

State-sponsored hackers

Hackers employed by a nation-state to carry out attacks, usually against other nation-states.

Hacktivists

Easily confused with Cyber Terrorists above, hactivists are motivated by a political agenda, and oftentimes carry this out by defacing or disabling websites.

Hacker teams

Groups of skilled hackers with their own resources who work together, usually in a research effort.

Industrial spies

Individuals who carry out attacks for the purpose of corporate espionage.

Insiders

Trusted users carrying out attacks from within the organization. Insiders are notoriously difficult to stop, as they have already been granted access and elevated privileges.

Criminal syndicates

Organized crime attackers who are in this for the money.

Organized hackers

Criminally minded individuals who carry out attacks with rented assets to gain money from targets.

Before you freak out about the purposefully confusing wording of these hacker classifications, take heart – while you will see them mentioned on the exam, they won’t make or break you. This is just one of those areas where you simply have to recognize differences between the exam versus real life, and concentrate on the exact wording of each definition. For one example, note that in the definition provided, hacktivists tend to use website defacement in support of a political agenda, whereas cyber terrorists are motivated by religious or political beliefs with the intent to cause fear. The exact wording matters, so pay close attention.

Attack Types

Another thing you should memorize is the various types of attacks a hacker could attempt, as defined by the EC Council. Categorizing attacks in and of itself may seem fairly silly to you - after all, do you care what the attack type is called if it works for you? It means a heck of a lot for your exam, though.

For this certification effort, EC Council broadly defines five attack types:

Passive Attacks 

Generally, simple monitoring efforts, such as sniffing or eavesdropping. No data is meddled with and nothing is altered. Intercept traffic and watch or listen – that’s it.

Active Attacks 

These attacks are the exact opposite of passive attacks; you actively tamper, change, alter or delete data, or interrupt communications. Active attacks carry a much higher risk of discovery.

Close-in Attacks 

These attacks are performed when the attacker is physically close to the target. For example, a shoulder surfer may watch someone log in to gain access.

Insider Attacks 

These attacks are carried out by people who already have some form of access and elevated privileges as an employee, security member, or otherwise. This makes it easy to plant spyware, keyloggers, or even physically steal assets.

Distribution Attacks 

These attacks are carried out before the target system is even delivered to the customer. The attackers tamper with the hardware or software before it’s installed at the client location.

The types of attacks have changed in recent versions of the CEH study material. Operating System, Application-level, Shrink Wrap, and Misconfiguration were all once valid attack types. Just keep them in mind should they make a reoccurrence on your exam.

Warning

Infowar (as ECC loves to call it) is the use of offensive and defensive techniques to create advantage over your adversary. Defining which actions are offensive versus defensive should be self-explanatory, so if you’re asked, use common sense. For example, a banner on your system warning anyone attempting access that you’ll prosecute is defensive in nature, acting as a deterrent.

The Ethical Hacker

What makes someone an “ethical” hacker? Can such a thing even exist? Since the art of hacking computers and systems is, in and of itself, a covert action, most people might see it as significantly unethical. However, the purpose and intention of the act have to be taken into account.

For comparison’s sake, law enforcement professionals routinely take part in unethical behaviors and situations in order to better understand, and to catch, their criminal counterparts. Police and FBI agents must learn the lingo, actions, and behaviors of drug cartels and organized crime in order to infiltrate and bust the criminals, and doing so sometimes forces them to engage in criminal acts themselves. Ethical hacking can be thought of in much the same way. To find and fix the vulnerabilities and security holes in a computer system or network, you sometimes have to think like a criminal and use the same tactics, tools, and processes they might employ.

CEH and several other entities distinguish between a hacker and a cracker. An ethical hacker is someone who employs the same tools and techniques a criminal might use, with the customer’s full support and approval, to help secure a network or system. A cracker, also known as a malicious hacker, uses those skills, tools, and techniques for personal gain, for destructive purposes, or, in purely technical terms, to achieve a goal outside the interest of the system owner. Ethical hackers are employed by customers to improve security. Crackers act on their own or, in some cases, as hired agents to destroy or damage government or corporate reputation.

There’s one all-important difference between an ethical hacker and a bad-guy cracker that I’ll highlight and repeat over and over throughout this book:

Ethical hackers work within the confines of an agreement they make with a customer before they take any action.

This agreement isn’t simply a smile, a conversation, and a handshake just before you flip open a laptop and start hacking away. It is a carefully laid-out plan, meticulously arranged and documented to protect both hacker and the client.

In general, an ethical hacker will first meet with the client and sign a contract. The contract defines the permission and authorization the client is granting the security professional (sometimes called a get-out-of-jail-free card) as well as the scope of the action to be taken. It also contains a confidentiality clause. No client would ever agree to having an ethical hacker attempt to breach security without first ensuring that the hacker will not disclose any information they find during the test. Usually, this takes the form of a nondisclosure agreement (NDA).

In terms of scope, clients almost always want the test to proceed to a certain point in the network structure and no further: “You can try to get through the firewall, but do not touch the file servers on the other side… because you may disturb my MP3 collection.” They may also want to restrict what types of attacks you run. For example, the client may be perfectly okay with you attempting a password hack against their systems but may not want you to test every DoS attack you know.

Often, however, clients will forbid you to test the most serious risks to a target because of the “criticality of the resource”--even though they’ve hired you to test their security and you know what’s really important in security and hacking circles. This, by the way, is often a function of corporate trust between the pen tester and the organization and will shift over time; what’s a critical resource in today’s test will become a focus of scrutiny and “Let’s see what happens” next year. As trust increases between target and pen tester, the likelihood of being allowed to test critical and vital systems also increases. A pen tester shouldn’t expect a new client or customer to allow unrestricted testing of anything and everything until a pattern of trust is established. If the test designed to improve security actually blows up a server, it may not be a winning scenario; however, sometimes the data that is actually at risk makes it important enough to proceed. This really boils down to cool and focused minds during the security testing negotiation.

Another common issue is that what is considered “too secure to test” actually turns out to be the most vulnerable system. A pen tester interview with the client might go like this: “What about that crusty Solaris box that runs all the backend processing for payroll and hasn’t been updated since 2002?” “Well, it’s really important and if it breaks, the organization dies. We have compensating controls for stuff like that.” It’s like a sunshine law for cyber—no mold grows where the pen-test light shines.

The Pen Test

Companies and government agencies ask for penetration tests for a variety of reasons. Sometimes rules and regulations force the issue. For example, many US medical facilities need to maintain compliance with the Health Insurance Portability and Accountability Act (HIPAA) and will hire ethical hackers to complete their accreditation. Sometimes the organization’s leadership is security-conscious and wants to know just how well the existing security controls are functioning. Other times, it’s an effort to rebuild trust and reputation after a security breach has already occurred. It’s one thing to tell customers you’ve fixed the security flaw that allowed the theft of all those credit card numbers in the first place. It’s another thing altogether to show the results of a penetration test against the new controls.

With regard to your exam and to your future as an ethical hacker, there are two processes you’ll need to know: how to set up and perform a legal penetration test and how to proceed through the actual hack. For the CEH exam, you’ll need to be familiar with the three pen-test stages and the five stages of a typical hack.

A penetration test is a clearly defined, full-scale test of the security controls of a system or network in order to identify security risks and vulnerabilities. Once the ethical hacker and customer agree on the pen test’s parameters, the ethical hacker begins the “assault.” They may use a variety of tools, methods, and techniques, but generally follow the same five stages of a typical hack to conduct the test.

A pen test has three main phases”:

Preparation

The preparation phase defines the time period during which the actual contract is hammered out. The scope of the test, the types of attacks allowed, and the individuals assigned to perform the activity are all agreed upon in this phase.

Assessment

The assessment phase (sometimes also known as the security evaluation phase or the conduct phase) is exactly what it sounds like—the actual assaults on the security controls are conducted during this time.

Conclusion

The conclusion (or post-assessment) phase is when the tester prepares final reports for the customer, detailing the tests performed, their findings, and (often) recommendations to improve security.

In performing a pen test, an ethical hacker must attempt to reflect the criminal world as much as possible. In other words, if their steps don’t adequately mirror what a “real” hacker would do, then the test is doomed to failure. For that reason, most pen tests specify how much knowledge the tester will have about the target of evaluation (TOE). These different types of tests are known by another color system: black box, white box, and gray box.

Note

In my humble opinion, pen tests fall into two main types: one that intends to fully find and explore all of the vulnerabilities within a designated system, and the other that seeks only to determine if, how, and how easily a system can be exploited through vulnerabilities. The criminal world isn’t going to do you the favor of a full-scale test.

In black-box testing, the ethical hacker has absolutely no knowledge of the TOE. The testing is designed to simulate an outside, unknown attacker. It takes the most time to complete and is usually the most expensive option by far. For the ethical hacker, black-box testing means a thorough romp through the five stages of an attack without any preconceived notions of what to look for. The only true drawback to this type of test is that it focuses solely on external threats to the organization and does not account for insider attacks.

An important “real world versus definition” distinction arises here: While the pure definition of the term implies no knowledge, a black-box test is designed to mirror the knowledge an external hacker has before starting an attack. Rest assured, the bad guys have been researching things for a long time. They know something, or they wouldn’t attack in the first place. As a pen tester, you’d better be aware of the same things they are when setting up your test. Additionally, having a trusted internal agent before you take action is essential to avoid inadvertently breaking the law and hacking someone else. You must have some means to verify that you are attacking only those things within the scope of the assessment; if you know nothing, you can easily attack things which do not belong to the target organization.

White-box testing is the exact opposite of black-box testing. In this type, pen testers have full knowledge of the network, system, and infrastructure they’re targeting. This makes the test much quicker, easier, and less expensive. White-box testing is designed to simulate a knowledgeable internal threat, such as a disgruntled network admin or other trusted user.

The last type, gray-box testing, is also known as partial knowledge testing. What makes this different from black-box testing is the assumed level of elevated privileges the tester has. Whereas black-box testing is generally done from the network administration level, gray-box testing assumes only that the attacker is an insider. Because most attacks do originate from inside a network, this type of testing is valuable and can demonstrate privilege escalation from a trusted employee.

Laws and Standards

Finally, it would be impossible to call yourself an ethical anything if you didn’t understand the guidelines, standards, and laws that govern your particular area of expertise. In IT security and in ethical hacking, there are tons of laws and standards you should be familiar with. Not only will this help you do a good job, it’ll keep you out of trouble—and prison. Previous versions of the exam didn’t ask about these laws and standards very often, but now they’re back—with a vengeance.

I would love to provide you a comprehensive list of every law you’ll need to know, but if I did, this book would be the size of an old encyclopedia and you’d never buy it. There are tons of laws you need to be aware of for your job, such as FISMA, Electronics Communications Privacy Act, PATRIOT Act, Privacy Act of 1974, Cyber Intelligence Sharing and Protection Act (CISPA), Consumer Data Security and Notification Act, Computer Security Act of 1987…the list really is almost endless. Since this isn’t a book to prepare you for a state bar exam, I’m not going to get into defining all these. For the sake of study, and keeping my page count down somewhat, we’ll just discuss a few you should concentrate on for test purposes—mainly because they’re the ones ECC seems to be looking at closely this go-round. When you get out in the real world, you’ll need to learn, and know, the rest.

First up is the Health Insurance Portability and Accountability Act (HIPAA), developed by the U.S. Department of Health and Human Services to address privacy standards with regard to medical information. The law sets privacy standards to protect patient medical records and health information, which, by design, are provided and shared to doctors, hospitals, and insurance providers. HIPAA has five subsections: Electronic Transaction and Code Sets, Privacy Rule, Security Rule, National Identifier Requirements, and Enforcement. This may show up on your exam.

Another important law is the Sarbanes-Oxley (SOX) Act, created to make corporate disclosures more accurate and reliable in order to protect the public and investors from shady behavior. There are 11 titles within SOX that handle everything from what financials should be reported and what should go in them to protecting against auditor conflicts of interest and enforcement for accountability.

Note

One thing that may help you in setting up better security is the Open Source Security Testing Methodology Manual (OSSTMM—if you really want to sound snooty, call it “awstem”). It’s a peer-reviewed, formalized security testing and analysis methodology that aims to “provide actionable information to measurably improve your operational security.” It defines three types of compliance for testing: legislative (government regulations), contractual (industry or group requirements), and standards based (practices that must be followed in order to remain a member of a group or organization).

Other laws of note include the Digital Millenium Copyright Act (DMCA), a US copyright law defining specifically protecting the technological protection measures folks use to protect their copyrighted material. There’s the US’s Federal Information Security Management Act (FISMA), which CISA.gov defines as “federal legislation that defines a framework of guidelines and security standards to protect government information and operations.” The Data Protection Act (DPA) and the General Data Protection Regulation (GDPR) are frameworks for data protection law in the United Kingdom.

When it comes to standards, again there are tons to know. ECC really wants you to pay attention to the Payment Card Industry Data Security Standard (PCI-DSS), a security standard for organizations handling credit cards, ATM cards, and other point-of-sales cards. The standards apply to all groups and organizations involved in the entirety of the payment process—from card issuers, to merchants, to those storing and transmitting card information—and consist of 12 requirements.

Want more? I don’t either, so I’ll leave you with the last example. ECC also wants you to focus on the ISO/IEC 27001:2013 standard, which provides requirements for creating, maintaining, and improving organizational information security (IS) systems. The standard addresses legal issues such as ensuring compliance with laws as well as formulating internal security requirements and objectives.

Warning

Law is a funny thing, with semantic terms aplenty. Be aware of the differences between criminal law (a body of rules and statutes that defines conduct prohibited by the government because it threatens and harms public safety and welfare and that establishes punishment to be imposed for the commission of such acts), civil law (a body of rules that delineates private rights and remedies as well as governs disputes between individuals in such areas as contracts, property, and family law, distinct from criminal law), and so-called common law (law based on societal customs and recognized and enforced by the judgments and decrees of the courts). Anything you see question-wise on it should be easy enough to infer, but thought you should look into it regardless.

Finally, keep in mind that IS laws are tricky things when it comes to national borders. While it’s easy for the US to enforce a rule about planting seeds within the physical borders of the United States, that law means nothing in China, Australia, or France. When it comes to information and the Internet, though, things get trickier. The complexities of laws in other countries simply cannot be deciphered in one book. You will have to spend some time with your employer and your team to learn what you need to know before testing anything.

Note

Don’t forget one very simple, obvious observation some people just don’t think about: the Internet is global. The difference between hacking your target and hacking the government of China could be a simple as accidentally typing the wrong number in an IP address. And while most people believe traffic is malicious only if it targets your system specifically, others may see it as malicious if it just transits your system.

Conclusion

And thus, dear reader, we’ve waded into the shallow end of the pool of knowledge required for your certification. Yes it’s true, most of this chapter boils down to memorization of a lot of terms, and keeping track of various methodology steps and – don’t forget – laws and standards you’ll need to know. Just know that all of the information presented here truly is essential for your success, both in the real world and as a candidate for this certification. Now, let’s start swimming in the deeper regions of this pool, starting with Footprinting...

Review Questions

1. A Certified Ethical Hacker (CEH) follows a specific methodology for testing a system. Which step comes after footprinting in the CEH methodology?¹

   1. Scanning
   2. Enumeration
   3. Reconnaissance
   4. Application

2. You’ve been hired as part of a pen test team. During the brief, you learn the client wants the pen test attack to simulate a normal user who finds ways to elevate privileges and create attacks. Which test type does the client want?²

   1. White box
   2. Gray box
   3. Black box
   4. Hybrid

3. Which of the following statements is true regarding the TCP three-way handshake?³

   1. The recipient sets the initial sequence number in the second step.
   2. The sender sets the initial sequence number in the third step.
   3. When accepting the communications request, the recipient responds with an acknowledgement and a randomly generated sequence number in the second step.
   4. When accepting the communications request, the recipient responds with an acknowledgement and a randomly generated sequence number in the third step.

4. An ethical hacker is given no prior knowledge of the network and has a specific framework in which to work. The agreement specifies boundaries, nondisclosure agreements, and a completion date definition. Which of the following statements is true?⁴

   1. A white hat is attempting a black-box test.
   2. A white hat is attempting a white-box test.
   3. A black hat is attempting a black-box test.
   4. A black hat is attempting a gray-box test.

5. As part of a pen test on a U.S. government system, you discover files containing Social Security numbers and other sensitive personally identifiable information (PII). You are asked about controls placed on the dissemination of this information. Which of the following acts should you check?⁵

   1. FISMA
   2. Privacy Act
   3. PATRIOT Act
   4. Freedom of Information Act

6. In which step of the Cyber Kill Chain methodology would an adversary create a deliverable malicious payload?⁶

   1. Command and Control (C2)
   2. Weaponization
   3. Installation
   4. Exploitation

7. Which of the following is best defined as a set of processes used to identify, analyze, prioritize, and resolve security incidents?⁷

   1. Incident management
   2. Vulnerability management
   3. Change management
   4. Patch management

¹ a.

² b.

³ c.

⁴ a.

⁵ b.

⁶ b.

⁷ b.