H2

CHAPTER 1 Getting Started: Essential Knowledge

In this chapter, you will

•   Identify components of TCP/IP computer networking

•   Understand basic elements of information security

•   Understand incident management steps

•   Identify fundamentals of security policies

•   Identify essential terminology associated with ethical hacking

•   Define ethical hacker and classifications of hackers

•   Describe the five stages of ethical hacking

•   Define the types of system attacks

•   Identify laws, acts, and standards affecting IT security

Last year, 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 be-

came 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 narrowing

down the culprit, I called the handy help desk line to get a new

router ordered and delivered for me to install myself, or to get a

friendly in-home visit to take the old one and replace it. After an-

swering the phone and taking a couple basic, and perfectly rea-

sonable, 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 of dealing with it

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 survived the gauntlet and 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 the latest version of this book. I got to

looking at the previous chapters and thought to myself, “What

were you thinking? Why were you telling them about network-

ing and the OSI model? You’re the help desk guy here.”

Why? Because I have to. I’ve promised to cover everything

here, and 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: this edition

has hopefully cut down some of the basic networking goodies

from past versions. I did have to include a fantastic explanation

of the OSI reference model, what PDUs are at what level, and

why you should care, even though I’m pretty sure you know this

already. I’m going to do my best to keep it better focused for you

and your study. This chapter still includes some inanely boring

and mundane information that is probably 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. We’ll cover the

many terms you’ll need to know, including what an ethical

hacker is supposed to be, and maybe even cover a couple things

you don’t know.

Security 101

If you’re going to start a journey toward an ethical hacking certi-

fication, it should follow that the fundamental definitions and

terminology involved with security should be right at the start-

ing line. We’re not going to cover everything involved in IT secu-

rity 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 wad-

ing out of the shallow end. This chapter covers the terms you’ll

need to know to sound intelligent when discussing security mat-

ters with other folks. And, perhaps just as importantly, we’ll

cover some basics of TCP/IP networking because, 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 in our romp through the introductory topics here, there are

a couple things I need to get out of the way. First, even though I

covered most of this in that Shakespearean introduction for the

book, I want to talk a little bit about this exam and what you

need to know, and do, to pass it. Why repeat myself? Because af-

ter reading reviews, comments, and e-mails from our first few

outings, it has come to my attention almost none of you actually

read the introduction. I don’t blame you; I skip it too on most

certification study books, just going right for the meat. But

there’s good stuff there you really need to know before reading

further, so I’ll do a quick rundown for you up front.

Second, 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 makes perfect common sense,

and some of it is, or should be, just plain easy. You’re really sup-

posed to know this already, and you’ll see this stuff again and

again throughout this book, but it’s truly bedrock stuff and I

would be remiss if I didn’t at least provide a jumping-off point.

The Exam

Are you sitting down? Is your heart healthy? I don’t want to dis-

tress you with this shocking revelation I’m about to throw out,

so if you need a moment, go pour a bourbon (another refrain

you’ll see referenced throughout this book) and get calm before

you read further. Are you ready? The CEH version 10 exam is

difficult, and despite hours (days, weeks) of study and multiple

study sources, you may still come across a version of the exam

that leaves you feeling like you’ve been hit by a truck.

I know. A guy writing and selling a study book just told you it

won’t be enough. Trust me when I say it, though, I’m not kid-

ding. Of course this will be a good study reference. Of course you

can learn something from it if you really want to. Of course I did

everything I could to make it as up to date and comprehensive

as possible. But if you’re under the insane assumption this is a

magic ticket, that somehow written word from October 2018 is

going to magically hit the word-for-word reference on a specific

test question in whatever timeframe/year you’re reading this, I

sincerely encourage you to find some professional help before

the furniture starts talking to you and the cat starts making

sense. Those of you looking for exact test questions and rote

memorization to pass the exam will not find it in this publica-

tion, nor any other. For the rest of you, those who want a little fo-

cused attention to prepare the right way for the exam and those

looking to learn what it really means to be an ethical hacker,

let’s get going with your test basics.

NOTE    I’ve been asked, a lot, what the difference is between

version 9 and version 10, and the answer is, really, not much. EC-

Council (ECC) added a bunch of stuff they tossed together as

“IoT,” beefed up a little cloud computing, and threw a few new

tools in for consideration. Otherwise, networking is still net-

working, and the same stuff you studied for previous versions

will apply here.

First, if you’ve never taken a certification-level exam, I

wouldn’t recommend this one as your virgin experience. It’s

tough enough without all the distractions and nerves involved in

your first walkthrough. When you do arrive for your exam, you

usually check in with a friendly test proctor or receptionist, sign

a few things, and get funneled off to your testing room. Every

time I’ve gone it has been a smallish office or a closed-in cubicle,

with a single monitor staring at you ominously. You’ll click

START and begin whizzing through questions one by one, click-

ing the circle to select the best answer(s) or clicking and drag-

ging definitions to the correct section. At the end there’s a

SUBMIT button, which you will click and then enter a break in

the time-space continuum—because the next 10 seconds will

seem like the longest of your life. In fact, it’ll seem like an eter-

nity, where things have slowed down so much you can actually

watch the refresh rate on the monitor and notice the cycles of AC

current flowing through the office lamps. When the results page

finally appears, it’s a moment of overwhelming relief or one of

surreal numbness.

If you pass, none of the study material matters and, frankly,

you’ll almost immediately start dumping the stored memory

from your neurons. If you don’t pass, everything matters. You’ll

race to the car and start marking down everything you can re-

member so you can study better next time. You’ll fly to social

media and the Internet to discuss what went wrong and to lam-

bast anything you didn’t find useful in preparation. And you’ll

almost certainly look for something, someone to blame. Trust

me, don’t do this.

Everything you do in preparation for this exam should be

done to make you a better ethical hacker, not to pass a test. If you

prepare as if this is your job, if you take everything you can use

for study material and try to learn instead of memorize, you’ll

be better off, pass or fail. And, consequentially, I guarantee if

you prepare this way your odds of passing any version of the test

that comes out go up astronomically.

The test itself? Well, there are some tips and tricks that can

help. I highly recommend you go back to the introduction and

read the sections “The Examination” and “The Certification.”

They’ll help you. A lot. Here are some other tips that may help:

•   Do not let real life trump EC-Council’s view of it. There will be

several instances somewhere along your study and eventual

exam life where you will say, aloud, “That’s not what happens in

the real world! Anyone claiming that would be stuffed in a

locker and sprayed head to toe with shaving cream!” Trust me

when I say this: real life and a certification exam are not neces-

sarily always directly proportional. On some of these questions,

you’ll need to study and learn what you need for the exam,

knowing full well it’s different in the real world. If you don’t

know what I mean by this, ask someone who has been doing this

for a while if they think social engineering is passive.

•   Go to the bathroom before you enter your test room. Even if you

don’t have to. Because, trust me, you do.

•   Use time to your advantage. The exam now is split into sections,

with a timeframe set up for each one. You can work and review

inside the section all you want, but once you pass through it you

can’t go back. And if you fly through a section, you don’t get

more time on the next one. Take your time and review

appropriately.

•   Make use of the paper and pencil/pen the friendly test proctor

provides you. As soon as you sit down, before you click START on

the ominous test monitor display, start writing down everything

from your head onto the paper provided. I would recommend

reviewing just before you walk into the test center those sections

of information you’re having the most trouble remembering.

When you get to your test room, write them down immediately.

That way, when you’re losing your mind a third of the way

through the exam and start panicking that you can’t remember

what an XMAS scan returns on a closed port, you’ll have a refer-

ence. And trust me, having it there makes it easier for you to re-

call the information, even if you never look at it.

•   Trust your instincts. When you do question review, unless you

absolutely, positively, beyond any shadow of a doubt know you

initially marked the wrong answer, do not change it.

•   Take the questions at face value. I know many people who don’t

do well on exams because they’re trying to figure out what the

test writer meant when putting the question together. Don’t read

into a question; just answer it and move on.

•   Schedule your exam sooner than you think you’ll be ready for it.

I say this because I know people who say, “I’m going to study for

six months and then I’ll be ready to take the exam.” Six months

pass and they’re still sitting there, studying and preparing. If you

do not put it on the calendar to make yourself prepare, you’ll

never take it, because you’ll never be ready.

Again, it’s my intention that everyone reading this book and

using it as a valuable resource in preparation for the exam will

attain the certification, but I can’t guarantee you will. Because,

frankly, I don’t know you. I don’t know your work ethic, your at-

tention to detail, or your ability to effectively calm down to take

a test and discern reality from a certification definition question.

All I can do is provide you with the information, wish you the

best of luck, and turn you loose. Now, on with the show.

The OSI Reference Model

Most of us would rather take a ballpeen hammer to our toenails

than to hear about the OSI reference model again. It’s taught up

front in every networking class we all had to take in college, 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 for you to peruse, should you need to refresh

your memory.

I thought long and hard about the best way to go over this

topic again for our review, and decided I’d ditch the same old

boring method of talking this through. 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. Step in the

Wayback Machine with Sherman, Mr. Peabody, and me, and let’s

go back before networking was invented. How would you do it?

NOTE    Even something as simple as the OSI model can get re-

ally overcomplicated if you read enough into it. For example’s

sake, we’re looking at it in this text as it relates to TCP/IP. While

TCP/IP generally rules the networking world, there are other

protocol stacks that do much the same thing. The OSI model just

helps us to talk about their networked connections.

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 will you use to connect your

computers together so they can transmit signals? In other words,

what media would you use? There are several options: copper

cabling, glass tubes, even radio waves, among others. And de-

pending on which one of those you pick, you’re going to have to

figure out how to use them to transmit useable information.

How will you get an electrical signal on the wire to mean some-

thing 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, 1’s and 0’s.

Layer 2 then helps answer the questions involved in growing

your network. In figuring out how you would build this whole

thing, 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

media is shared, how would you guarantee everyone gets a

chance to talk, and no one’s message jumbles up anyone else’s?

The Data Link layer (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 particu-

lar network.

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 com-

puter knows where all the other computers in the neighborhood

reside, but sooner or later you’re going to want to send a mes-

sage to another neighborhood—maybe even another city. And

you certainly can’t expect each computer to know the address of

every computer in the whole world. This is where Layer 3 steps

in, with the packet used to hold network addresses and routing

information. It works a lot like ZIP 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 ad-

dress from Layer 3 tells routers along the way which neighbor-

hood (network) the message is intended for.

Other considerations then come into play, like reliable deliv-

ery and flow control. You certainly wouldn’t want a message just

blasting out without having any idea if it made it to the recipi-

ent; then again, you may want to, depending on what the mes-

sage is about. And you definitely wouldn’t want to overwhelm

the media’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 (through retransmission of missing segments) and

flow control.

At this point you’ve set the stage for success. There is media to

carry a signal (and you’ve figured how to encode that signal onto

that media), addressing inside and outside your network is han-

dled, and you’ve taken care of things like flow control and relia-

bility. Now it’s time to look upward toward the machines them-

selves and make sure they know how to do what they need to do.

The next three layers (from the bottom up—Session,

Presentation, and Application) handle the data itself. The Session

layer is more 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 for-

mat all systems can understand. For example, an e-mail crafted

in Microsoft Outlook may not necessarily be received by a ma-

chine running Outlook, so it must be translated into something

any receiver can comprehend—like pure ASCII code for delivery

across a network. The Application layer holds all the protocols

that allow a user to access information on and across a network.

For example, FTP allows users to transport files across networks,

SMTP provides for e-mail traffic, and HTTP allows you to surf

the Internet at work while you’re supposed to be doing some-

thing 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.

The layers, and examples of the protocols you’d find in them,

are shown in Figure 1-1.

Figure 1-1 OSI reference model

EXAM TIP    Your OSI knowledge on the test won’t be something

as simple as a question of what protocol data unit goes with

which layer. Rather, you’ll be asked questions that knowledge of

the model will help with; knowing what happens at a given layer

will assist you in remembering what tool or protocol the ques-

tion is asking about. Anagrams 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 im-

portant 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 ar-

ranged 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 al-

ready and simply follow a message from one machine to an-

other 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.

Suppose, for example, user Joe wants to get ready for the sea-

son opener and decides to do a little online shopping for his fa-

vorite University of Alabama football gear. Joe begins by open-

ing his browser and typing in a request for his favorite website.

His computer now has a data request from the browser that it

looks at and determines cannot be answered internally—that is,

not locally to Joe’s system. Why? Because the browser wants a

page that is not stored locally. So, now searching for a network

entity to answer the request, it chooses the protocol it knows the

answer for this request will come back on (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 or-

der. These collections of bits in a specific order are called frames

(Figure 1-3 shows a basic Ethernet frame), are built from the in-

side out, and rely on information handed down from upper lay-

ers. In this example, the Application layer will “hand down” an

HTTP request (data) to the Transport layer. At this layer, Joe’s

computer looks at the HTTP request and (because it knows HTTP

usually works this way) knows this needs to be a connection-ori-

ented session, with stellar reliability to ensure Joe gets every-

thing he asks for without losing anything. It calls on the

Transmission Control Protocol (TCP) for that. TCP will go out in a

series of messages to set up a communications session with the

end station, 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 seg-

ment asking the other computer whether it’s awake and wants

to talk—gets handed down for addressing to the Internet layer.

Figure 1-3 An Ethernet frame

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). It does its job by using another

protocol (DNS) to ask what IP address belongs to the URL Joe

typed. When that answer comes back, it builds a packet for deliv-

ery (which consists of the original data request, the TCP header

[SYN], and the IP packet information affixed just before it) and

“hands down” the packet to the Network Access layer for

delivery.

EXAM TIP    I know it’s not covered right here (we’re going to get

to it later in Chapter 3), but you really need to know subnetting.

You’ll see anywhere from two to five questions per exam on it.

There are dozens and dozens of good resources on the Internet

to help you on this—just search for “learn subnetting” or some-

thing like that and practice.

Here, Joe’s computer needs to find an address on its local sub-

net to deliver the packet to (because every computer is only con-

cerned with, and capable of, sending a message to a machine in-

side its own subnet). It knows its own physical address but has

no idea what physical address belongs to the system that will be

answering. The IP address of this device is known—thanks to

DNS—but the local, physical address is not. To gain that, Joe’s

computer employs yet another protocol, ARP, to figure that out,

and when that answer comes back (in this case, the gateway, or

local router port), the frame can then be built and sent out to the

network (for you network purists out there screaming that 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 forward

the frame to is repeated at every link in the network chain: ev-

ery time the frame is received by a router along the way, the

router 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, the server

will keep stripping off and handing up bit, frame, packet, seg-

ment, and data PDUs, which should result—if everything has

worked right—in the return of 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 the frames at each

link in the chain from Joe’s computer to a server in Figure 1-4.

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 will change, but IPs never do.

Figure 1-4 Ethernet frames in transit

EXAM TIP    Learn the three-way handshake, expressed as SYN,

SYN/ACK, ACK. Know it. Live it. Love it. You will get asked about

this, in many ways and formats, several times on your exam.

Although tons and tons of stuff has been left out—such as port

and sequence numbers, which will be of great importance to

you later—this touches on all the basics for TCP/IP networking.

We’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. Patience, Grasshopper—this is just an introduction,

remember?

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.

The five zones ECC defines are as follows:

•   Internet Outside the boundary and uncontrolled. You don’t ap-

ply security policies to the Internet. Governments try to all the

time, but your organization can’t.

•   Internet DMZ The acronym DMZ (for Demilitarized Zone) comes

from the military and refers to a section of land between two ad-

versarial parties where there are no weapons or fighting. The

idea is 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 un-

controlled chaos of the Internet.

NOTE    DMZs aren’t just between the Internet and a network;

they can be anywhere an organization decides they want or

need a buffer—inside or outside various internets and intranets.

DMZ networks provide great opportunity for good security mea-

sures, but can also sometimes become an Achilles’ heel when too

much trust is put into their creation and maintenance.

•   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 little-to-no heavy re-

strictions. This is not to say everything is wide open on the

Intranet Zone, but communication requires fewer strict controls

internally.

•   Management Network Zone Usually an area you’d find rife

with VLANs and maybe controlled via IPSec and such. This is a

highly secured zone with very strict policies.

Vulnerabilities

I struggled with just where, when, and how to add a discussion

on vulnerabilities in this book we’re putting together and finally

landed on here as the best place. Why? Because this is bedrock,

101-type information that many in security just assume you al-

ready know. I know it seems easy enough, and you can find vast

resources out there to help educate yourself quickly, but it seems

to me if nobody actually shows or tells you the hows and whys

on something, how can you be expected to just know it?

In our romp through “things you’re already supposed to

know,” we need to spend a few cursory moments on what, ex-

actly, defines a vulnerability and a few basics on vulnerabilities

in particular. A vulnerability is simply a weakness that can be

exploited by an attacker to perform unauthorized actions within

a computer or network system. Since our job as security profes-

sionals is to keep our systems safe, and your job as a pen tester is

to point out the weaknesses in security design, it follows that we

should all know vulnerability management well and do our best

at keeping vulnerabilities to a minimum.

So how does one know what vulnerabilities are out there and

what dangers they might provide? And is there a ranking system

of sorts 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 (technet.microsoft.com)

•   Security Focus (www.securityfocus.com)

•   Hackerstorm (www.hackerstorm.co.uk)

•   Exploit Database (www.exploit-db.com)

•   Security Magazine (www.securitymagazine.com)

•   Trend Micro (www.trendmicro.com)

•   Dark Reading (www.darkreading.com)

Next, if you’re looking for ways to quantify the danger or risk

particular vulnerabilities have, try the Common Vulnerability

Scoring System (CVSS, https://www.first.org/cvss/), which is “a

published standard used by organizations worldwide” and “pro-

vides a way to capture the principal characteristics of a vulnera-

bility and produce a numerical score reflecting its severity. The

numerical score can then be translated into a qualitative repre-

sentation (such as low, medium, high, and critical) to help orga-

nizations properly assess and prioritize their vulnerability man-

agement processes.” Want more? How about the National

Vulnerability Database (NVD, https://nvd.nist.gov/vuln-

metrics/cvss), 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 measure-

ment, and compliance.”

As a pen tester, you need to remain as up to date on active

vulnerabilities as possible (knowledge of new ones pop up all

the time). ECC drops all vulnerabilities into a series of categories,

and they are for the most part self-explanatory:

•   Misconfiguration A misconfiguration of the service or applica-

tion settings.

•   Default Installations Sometimes the installation of an applica-

tion or service using default locations and settings opens a vul-

nerability (sometimes discovered well after the release of the ap-

plication or service).

•   Buffer Overflows Covered later in this book, buffer overflows

are flaws in execution allowing an attacker to take advantage of

bad coding.

•   Missing Patches (Unpatched Servers) Despite patching for a

known security flaw being available, many systems are not

patched for a variety of reasons, leaving them vulnerable to

attack.

•   Design Flaws These are flaws universal to all operating systems

—things like encryption, data validation, logic flaws, and so on.

•   Operating System Flaws These are flaws in a specific OS

(Windows versus Linux, and so on).

•   Application Flaws Flaws inherit to the application coding and

function itself.

•   Open Services Services that are not actively used on the system

but remain open anyway (usually due to negligence or igno-

rance) can be targets.

•   Default Passwords Leaving a default password in place on a

system is asking for trouble.

Lastly, just because a vulnerability exists doesn’t necessarily

mean your system is at huge risk. For example, my computer sit-

ting 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 a bear is gonna come through my

front door and, maybe enraged by the red LED stripes across the

front and back, attack the 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: vulnera-

bilities are always present on your system, and your job as a se-

curity professional is to put as many security controls as realisti-

cally possible in place to prevent their exploitation.

Vulnerability and risk assessments are designed specifically to

look at potential vulnerabilities on your system versus the actual

likelihood of their exploitation. How hard would it be to exploit

the vulnerability? Is it even possible for an attacker given the se-

curity 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? All of these are questions auditors and se-

curity folks deal with on a daily basis. 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.

NOTE    Vulnerability management tools, as listed and defined

by ECC, include but are not limited to Nessus

(www.tenable.com), Qualys (www.qualys.com), GFI Languard

(www.gfi.com), Nikto (https://cirt.net), OpenVAS

(www.openvas.org), and Retina CS (www.beyondtrust.com).

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 the 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 contex-

tual clues in a story.

Bob and Joe used to be friends in college, but had a falling out

over doughnuts. Bob insisted Krispy Kreme’s 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 exploring opportunities as they presented

themselves. 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.

After starting, Bob noticed most decisions at OP were made in

favor of usability over functionality and security. He showed a

Security, Functionality, and Usability triangle (see Figure 1-5) to

upper management, visually displaying that moving toward one

of the three lessened the other two, and security was sure to suf-

fer 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

One day a few weeks later, 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. In doing so, 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 soft-

ware flaws or logic design errors. A particular vulnerability did

show up on the target, so Joe researched attack vectors and dis-

covered—through his super-secret hacking background contacts

—an attack the developer of some software on the target appar-

ently 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 he

could inject through a hacking tactic he thought would work.

After obfuscating this payload and embedding it in an attack, he

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 all. His daisy-chaining of network access

then gave him options to set up several machines on multiple

networks he could control remotely to execute really whatever

he wanted. These bots could be accessed any time he wanted, so

Joe decided to prep for more carnage. He also searched publicly

available databases and social media for personally identifiable

information (PII) about Bob and then posted his findings. After

this doxing effort, Joe took a nap, dreaming about what embar-

rassment Bob would have rain down on him the next day.

EXAM TIP    Another fantastic bit of terminology from ECC-land

you may see 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 worries that

something is amiss, and wonders if his old nemesis is back and

on the attack. He does some digging and discovers Joe’s attack

from the previous evening, and immediately engages his inci-

dent response team (IRT) to identify, analyze, prioritize, and re-

solve the incident. The team first reviews detection and quickly

analyzes the exploitation, in order to notify the appropriate

stakeholders. The team then works to contain the exploitation,

eradicate residual back doors and such, and coordinate recovery

for any lost data or services. After following this incident man-

agement process, the team provides post-incident reporting and

lessons learned to management.

NOTE    Here’s a great three-dollar term you might see on the

exam: EISA. Enterprise Information Security Architecture is a

collection of requirements and processes that help determine

how an organization’s information systems are built and how

they work.

Post-incident reporting suggested to leadership they focus

more attention on security, and, in one section of the report in

particular, that they adopt the means to identify what risks are

present and quantify them on a measurement scale. This risk

management approach would allow them to come up with solu-

tions to mitigate, eliminate, or accept the identified risks (see

Figure 1-6 for a sample risk analysis matrix).

Figure 1-6 Risk analysis matrix

EXAM TIP    The risk management phases identified by EC-

Council are Risk Identification, Risk Assessment, Risk Treatment,

Risk Tracking, and Risk Review. Each phase is fairly self-explana-

tory, and you may see mention of them on your exam.

Identifying organizational assets, the threats to those assets,

and their vulnerabilities would allow the company to explore

which countermeasures security personnel could put into place

to minimize risks as much as possible. These security controls

would then greatly increase the security posture of the systems.

NOTE    Security controls can also be categorized as physical,

technical, and administrative. Physical controls include things

such as guards, lights, and cameras. Technical controls include

things such as encryption, smartcards, and access control lists.

Administrative controls include the training, awareness, and

policy efforts that are well intentioned, comprehensive, and well

thought out—and that most employees ignore. Hackers will com-

bat physical and technical controls to get to their end goal, but

they don’t give a rip about your administrative password policy

—unless it’s actually followed.

Some of these controls were to be put into place to prevent er-

rors or incidents from occurring in the first place, some were to

identify an incident had occurred or was in progress, and some

were designed for after the event to limit the extent of damage

and aid swift recovery. These preventative, detective, and correc-

tive controls can work together to reduce Joe’s ability to further

his side of the great Doughnut Fallout.

EXAM TIP    Know preventive, detective, and corrective mea-

sures. Examples of each include authentication (preventative),

alarm bells for unauthorized access to a physical location, alerts

on unauthorized access to resources, audits (detective), and

backups and restore options (corrective). You will definitely be

asked about them, in one way or another.

This effort spurred a greater focus on overall preparation and

security. Bob’s quick action averted what could have been a total

disaster, but everyone involved saw the need for better planning

and preparation. Bob and management kicked off an effort to

identify the systems and processes that were critical for opera-

tions. This business impact analysis (BIA) included measure-

ments of the maximum tolerable downtime (MTD), which pro-

vided a means to prioritize the recovery of assets should the

worst occur. Bob also branched out and created Orca Pig’s first

set of plans and procedures to follow in the event of a failure or

a disaster—security related or not—to get business services back

up and running. His business continuity plan (BCP) included a

disaster recovery plan (DRP), addressing exactly what to do to re-

cover 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 numbers and

value to his systems and services, the ALE (annualized loss ex-

pectancy) turned out to be the product of the ARO (annual rate of

occurrence) and the SLE (single loss expectancy). For his first ef-

fort, he looked at one system and determined its worth, includ-

ing the cost for return to service and any lost revenue during

downtime, was $120,000. Bob made an educated guess on the

percentage of loss for this asset if a specific threat was actually

realized and determined the exposure factor (EF) turned out to

be 25 percent. He multiplied this by the asset value and came up

with an SLE of $30,000 ($120,000 × 25%). He then figured out

what he felt would be the probability this would occur in any

particular 12-month period. Given statistics he garnered from

similarly protected businesses, he thought it could occur once

every five years, which gave him an ARO of 0.2 (one occurrence /

five years). By multiplying the estimate of a single loss versus

the number of times it was likely to occur in a year, Bob could

generate the ALE for this asset at $6000 ($30,000 × 0.2).

Repeating this across Orca Pig’s assets turned out to provide

valuable information for planning, preparation, and budgeting.

EXAM TIP    ALE = SLE × ARO. Know it. Trust me.

At the end of this effort week, Bob relaxed with a Maker’s

Mark and an Arturo Fuente on his back porch, smiling at all the

good security work he’d done and enjoying the bonus his leader-

ship provided as a reward. 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. Just wait and see. I won’t stop. Ever.”

NOTE    Oftentimes security folks tend to get caught up in the

101-level items and catch words we all know. We make sure we

investigate vulnerabilities, manage risks, and establish policies,

while we sometimes ignore the biggest issue we have right in

front of us—the users. ECC calls this out in User Behavior

Analytics (UBA). UBA is a process of tracking user behaviors

themselves, and extrapolating those behaviors in light of mali-

cious activity, attacks, and frauds. There are behavior-based in-

trusion detection systems (IDSs) out there, but don’t overlook

UBA in your own security efforts.

Now, wasn’t that better than just reading definitions? Sure,

there were a few leaps, and Bob surely wouldn’t be the guy do-

ing 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 remem-

ber 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 pass-

ing italics reference, 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

(CIA). Whether you’re an ethical hacker or not, these three items

constitute the hallmarks of security we all strive for. You’ll need

to be familiar with two aspects of each term in order to achieve

success as an ethical hacker as well as on the exam: what the

term itself means and which attacks are most commonly associ-

ated with it.

Confidentiality, addressing the secrecy and privacy of informa-

tion, refers to the measures taken both 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. Confidentiality for the individual is a

must, considering its loss could result in identity theft, fraud,

and loss of money. For a business or government agency, it could

be even worse. The use of passwords within some form of au-

thentication is by far the most common measure taken to ensure

confidentiality, and attacks against passwords are, amazingly

enough, the most common confidentiality attacks.

For example, your logon to a network usually consists of a

user ID and a password, which is designed to ensure 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 mas-

querade 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.

EXAM TIP    Be careful with the terms confidentiality and au-

thentication. Sometimes these two are used interchangeably, and

if you’re looking for only one, you may miss the question alto-

gether. For example, a MAC address spoof (using the MAC ad-

dress of another machine) is considered an authentication at-

tack. Authentication is definitely a major portion of the confi-

dentiality segment of IT security.

The Stone Left Unturned

Security professionals deal with, and worry about, risk manage-

ment a lot. We create and maintain security plans, deal with

endless audits, create and monitor ceaseless reporting to govern-

ment, and employ bunches of folks just to maintain “quality” as

it applies to the endless amounts of processes and procedures

we have to document. Yet with all this effort, there always seems

to be something left out—some stone left unturned that a bad

guy takes advantage of.

Don’t take my word for it; just check the news and the statis-

tics. Seemingly every day there is a news story about a major

data breach somewhere. OPM lost millions of PII records to

hackers. eBay had 145 million user accounts compromised.

JPMorgan Chase had over 70 million home and business records

compromised, and the list goes on and on. In 2015, per Breach

Level Index (http://breachlevelindex.com) statistics, over 3 bil-

lion data records—that we know about—were stolen, and the

vast majority were lost to a malicious outsider (not accidental,

state sponsored, or the always-concerning disgruntled employee

malicious insider).

All this leads to a couple questions. First, IT security profes-

sionals must be among the most masochistic people on the

planet. Why volunteer to do a job where you know, somewhere

along the line, you’re more than likely going to fail at it and, at

the very least, be yelled at over it? Second, if there are so many

professionals doing so much work and breaches still happen, is

there something outside their control that leads to these fail-

ures? As it turns out, the answer is “Not always, but oftentimes

YES.”

Sure, there were third-party failures in home-grown web ap-

plications to blame, and of course there were default passwords

left on outside-facing machines. There were also several legiti-

mate attacks that occurred because somebody, somewhere

didn’t take the right security measure to protect data. But, at

least for 2015, phish-ing and social engineering played a large

role in many cases, and zero-day attacks represented a huge seg-

ment of the attack vectors. Can security employees be held ac-

countable for users not paying attention to the endless array of

annual security training shoved down their throats advising

them against clicking on e-mail links? Should your security engi-

neer be called onto the carpet because employees still, still, just

give their passwords to people on the phone or over e-mail

when they’re asked for them? And I’m not even going to touch

zero day—if we could predict stuff like that, we’d all be lottery

winners.

Security folks can, and should, be held to account for ignoring

due diligence in implementing security on their networks. If a

system gets compromised because we were lax in providing

proper monitoring and oversight, and it leads to corporate-wide

issues, we should be called to account. But can we ever uncover

all those stones during our security efforts across an organiza-

tion? Even if some of those stones are based on human nature? I

fear the answer is no. Because some of them won’t budge.

Integrity refers to the methods and actions taken to protect

the 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 re-

cipient with no alteration. For example, imagine a buying agent

sending an e-mail to a customer offering the price of $300. If an

attacker somehow has altered the e-mail and changed the offer-

ing price to $3000, the integrity measures have failed, and the

transaction will not occur as intended, if at all. Oftentimes, at-

tacks on the integrity of information are designed to cause em-

barrassment or legitimate damage to the target.

Integrity in information systems is often ensured through the

use of a hash. A hash function is a one-way mathematical algo-

rithm (such as MD5 and SHA-1) that generates a specific, fixed-

length number (known as a hash value). When a user or system

sends a message, a hash value is also generated to send to the re-

cipient. If even a single bit is changed during the transmission of

the message, instead of showing the same output, the hash func-

tion will calculate and display a greatly different hash value on

the recipient system. Depending on the way the controls within

the system are designed, this would result in either a retransmis-

sion of the message or a complete shutdown of the session.

EXAM TIP    Bit flipping is one form of an integrity attack. In bit

flipping, the attacker isn’t interested in learning the entirety of

the plain-text message. Instead, bits are manipulated in the ci-

pher text itself to generate a predictable outcome in the plain

text once it is decrypted.

Availability is probably the simplest, easiest-to-understand

segment of the security triad, yet it should not be overlooked. It

refers to the communications systems and data being ready for

use when legitimate users need them. Many methods are used

for availability, depending on whether the discussion is about a

system, a network resource, or the data itself, but they all at-

tempt 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 re-

source or service and can take many forms. For example, attack-

ers could attempt to use all available bandwidth to the network

resource, or they may actively attempt to destroy a user’s au-

thentication 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 secu-

rity triad. I’ve seen several CEH 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 exam-

ple, digital signatures can be used to guarantee the authenticity

of the person sending a message. Come test time, this may help.

Access Control Systems

While we’re on the subject of computer security, I think it may

be helpful to step back and look at how we all got here, and take

a brief jog through some of the standards and terms that came

out of all of it. In the early days of computing and networking,

it’s pretty safe to say security wasn’t high on anyone’s to-do list.

As a matter of fact, in most instances security wasn’t even an af-

terthought, and unfortunately it wasn’t until things started get-

ting out of hand that anyone really started putting any effort

into it. The sad truth about a lot of security is that it came out of

a reactionary stance, and very little thought was put into it as a

proactive effort—until relatively recently, anyway.

This is not to say nobody tried at all. As a matter of fact, in

1983 some smart guys at the U.S. Department of Defense saw the

future need for protection of information (government informa-

tion, that is) and worked with the NSA to create the National

Computer Security Center (NCSC). This group got together and

created a variety of security manuals and steps, and published

them in a book series known as the “Rainbow Series.” The cen-

terpiece of this effort came out as the “Orange Book,” which held

something known as the Trusted Computer System Evaluation

Criteria (TCSEC).

TCSEC was a United States government Department of

Defense (DoD) standard, with a goal to set basic requirements

for testing the effectiveness of computer security controls built

into a computer system. The idea was simple: if your computer

system (network) was going to handle classified information, it

needed to comply with basic security settings. TCSEC defined

how to assess whether these controls were in place, and how

well they worked. The settings, evaluations, and notices in the

Orange Book (for their time) were well thought out and proved

their worth in the test of time, surviving all the way up to 2005.

However, as anyone in security can tell you, nothing lasts

forever.

TCSEC eventually gave way to the Common Criteria for

Information Technology Security Evaluation (also known as

Common Criteria, or CC). Common Criteria had actually been

around since 1999, and finally took precedence in 2005. It pro-

vided a way for vendors to make claims about their in-place se-

curity by following a set standard of controls and testing meth-

ods, resulting in something called an Evaluation Assurance Level

(EAL). For example, a vendor might create a tool, application, or

computer system and desire to make a security declaration.

They would then follow the controls and testing procedures to

have their system tested at the EAL (Levels 1–7) they wished to

have. Assuming the test was successful, the vendor could claim

“Successfully tested at EAL-4.”

Common Criteria is, basically, a testing standard designed to

reduce or remove vulnerabilities from a product before it is re-

leased. Besides EAL, three other terms are associated with this

effort you’ll need to remember:

•   Target of evaluation (TOE)   What is being tested

•   Security target (ST)   The documentation describing the TOE

and security requirements

•   Protection profile (PP)   A set of security requirements specifi-

cally for the type of product being tested

While there’s a whole lot more to it, suffice it to say CC was de-

signed to provide an assurance that the system is designed, im-

plemented, and tested according to a specific security level. It’s

used as the basis for government certifications and is usually

tested for U.S. government agencies.

Lastly in our jaunt through terminology and history regarding

security and testing, we have a couple terms to deal with. One of

these is the overall concept of access control itself. Access control

basically means restricting access to a resource in some selective

manner. There are numerous terms you can fling about in dis-

cussing this to make you sound really intelligent (subject, initia-

tor, authorization, and so on), but I’ll leave all that for the glos-

sary. Here, we’ll just talk about a couple of ways of implement-

ing access control: mandatory and discretionary.

Mandatory access control (abbreviated to MAC) is a method of

access control where security policy is controlled by a security

administrator: users can’t set access controls themselves. In

MAC, the operating system restricts the ability of an entity to ac-

cess a resource (or to perform some sort of task within the sys-

tem). For example, an entity (such as a process) might attempt to

access or alter an object (such as files, TCP or UDP ports, and so

on). When this occurs, a set of security attributes (set by the pol-

icy administrator) is examined by an authorization rule. If the

appropriate attributes are in place, the action is allowed.

By contrast, discretionary access control (DAC) puts a lot of

this power in the hands of the users themselves. DAC allows

users to set access controls on the resources they own or control.

Defined by the TCSEC as a means of “restricting access to objects

based on the identity of subjects and/or groups to which they be-

long,” the idea is controls are discretionary in the sense that a

subject with a certain access permission is capable of passing

that permission (perhaps indirectly) on to any other subject (un-

less restrained by mandatory access control). A couple of exam-

ples of DAC include NTFS permissions in Windows machines

and Unix’s use of users, groups, and read-write-execute

permissions.

EXAM TIP    You won’t see many questions concerning Common

Criteria or access control mechanisms on your exam, but I can

guarantee you’ll see at least a couple. Pay attention to the four

parts of Common Criteria (EAL, TOE, ST, and PP) and specific ex-

amples of access control.

Security Policies

When I saw EC-Council dedicating so much real estate in its writ-

ing to security policies, I groaned in agony. Any real practitioner

of security will tell you policy is a great thing, worthy of all the

time, effort, sweat, cursing, and mind-numbing days staring at a

template, if only you could get anyone to pay attention to it.

Security policy (when done correctly) can and should be the

foundation of a good security function within your business.

Unfortunately, it can also turn into a horrendous amount of

memorization and angst for certification test takers because it’s

not always clear.

A security policy can be defined as a document describing the

security controls implemented in a business to accomplish a

goal. Perhaps an even better way of putting it would be to say

the security policy defines exactly what your business believes is

the best way to secure its resources. Different policies address a

variety of issues, such as defining user behavior within and out-

side the system, preventing unauthorized access or manipula-

tion of resources, defining user rights, preventing disclosure of

sensitive information, and addressing legal liability for users

and partners. There are worlds of different security policy types,

with some of the more common ones identified here:

•   Access Control Policy This identifies the resources that need

protection and the rules in place to control access to those

resources.

•   Information Security Policy This identifies to employees what

company systems may be used for, what they cannot be used

for, and what the consequences are for breaking the rules.

Generally employees are required to sign a copy before access-

ing resources. Versions of this policy are also known as an

Acceptable Use Policy.

•   Information Protection Policy This defines information sensi-

tivity levels and who has access to those levels. It also addresses

how data is stored, transmitted, and destroyed.

•   Password Policy This defines everything imaginable about pass-

words within the organization, including length, complexity,

maximum and minimum age, and reuse.

•   E-mail Policy Sometimes also called the E-mail Security Policy,

this addresses the proper use of the company e-mail system.

•   Information Audit Policy This defines the framework for audit-

ing security within the organization. When, where, how, how of-

ten, and sometimes even who conducts information security au-

dits are described here.

There are many other types of security policies, and we could

go on and on, but you get the idea. Most policies are fairly easy

to understand simply based on the name. For example, it

shouldn’t be hard to determine that the Remote Access Policy

identifies who can have remote access to the system and how

they go about getting that access. Other easy-to-recognize poli-

cies include User Account, Firewall Management, Network

Connection, and Special Access.

Lastly, and I wince in including this because I can hear you

guys in the real world grumbling already, but believe it or not,

EC-Council also looks at policy through the prism of how tough it

is on users. A promiscuous policy is basically wide open,

whereas a permissive policy blocks only things that are known to

be dangerous. The next step up is a prudent policy, which pro-

vides maximum security but allows some potentially and known

dangerous services because of business needs. Finally, a para-

noid policy locks everything down, not even allowing the user to

open so much as an Internet browser.

EXAM TIP    In this discussion there are four other terms worth

committing to memory. Standards are mandatory rules used to

achieve consistency. Baselines provide the minimum security

level necessary. Guidelines are flexible, recommended actions

users are to take in the event there is no standard to follow. And,

finally, procedures are detailed step-by-step instructions for ac-

complishing a task or goal.

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 cor-

ner furiously typing away on a keyboard in an effort to break or

steal something. Unfortunately, a lot of that is true, and a lot of

people worldwide actively participate in these activities for that

very purpose. However, it’s important to realize there are differ-

ences between the good guys and the bad guys in this realm. It’s

the goal of this section to help define the two groups for you, as

well as provide some background on the basics.

Whether for noble or bad purposes, the art of hacking re-

mains the same. Using a specialized set of tools, techniques,

knowledge, and skills to bypass computer security measures al-

lows someone to “hack” into a computer or network. The pur-

pose behind their use of these tools and techniques is really the

only thing in question. Whereas some use these tools and tech-

niques for personal gain or profit, the good guys practice them

in order to better defend their systems and, in the process, pro-

vide insight on how to catch the bad guys.

Hacking Terminology

Like any other career field, hacking (ethical hacking) has its own

lingo and a myriad of terms to know. Hackers themselves, for in-

stance, have various terms and classifications to fall into. For ex-

ample, you may already know that a script kiddie is a person un-

educated in hacking techniques who simply makes use of freely

available (but oftentimes old and outdated) tools and techniques

on the Internet. And you probably already know that a phreaker

is someone who manipulates telecommunications systems in or-

der to make free calls. But there may be a few terms you’re unfa-

miliar 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 a 100-page chapter of endless defini-

tions and to attempt to assist you in maintaining your sanity in

studying for this exam, we’ll stick with the more pertinent infor-

mation you’ll need to remember, and I recommend you peruse

the glossary at the end of this book for more information. You’ll

see these terms used throughout the book anyway, and most of

them are fairly easy to figure out on your own, but don’t dis-

count 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.

EXAM TIP    Definition questions should be no-brainers on the

exam. Learn the hacker types, the stages of a hack, and other

definitions in the chapter—don’t miss the easy ones.

Hacker Classifications: The Hats

You can categorize a hacker in countless ways, but the “hat” sys-

tem seems to have stood the test of time. I don’t know if that’s

because hackers like Western movies or we’re all just fascinated

with cowboy fashion, but it’s definitely something you’ll see over

and over again on your exam. The hacking community in gen-

eral can be categorized into three separate classifications: the

good, the bad, and the undecided. In the world of IT security, this

designation is given as a hat color and should be fairly easy for

you to keep track of.

•   White hats Considered the good guys, these are the ethical hack-

ers, hired by a customer for the specific goal of testing and im-

proving 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, ille-

gally using their skills for either personal gain or malicious in-

tent. 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, with or

without customer permission, to demonstrate security flaws in

systems. In either case, hacking without a customer’s explicit

permission and direction is usually a crime.

NOTE    Lots of well-meaning hacker types have found employ-

ment in the security field by hacking into a system and then in-

forming the victim of the security flaws so that they can be fixed.

However, 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 subset of this community

uses its skills and talents to put forward a cause or a political

agenda. These people hack servers, deface websites, create

viruses, and generally wreak all sorts of havoc in cyberspace un-

der the assumption that their actions will force some societal

change or shed light on something they feel to be a political in-

justice. It’s not some new anomaly in human nature—people

have been protesting things since the dawn of time—it has just

moved from picket signs and marches to bits and bytes. In gen-

eral, regardless of the intentions, acts of “hacktivism” are usu-

ally illegal in nature.

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 to pull it off. Whereas we, as ethical hackers,

won’t touch anything until we’re given express consent to do so,

these hackers are much like hacktivists and feel that their rea-

son for hacking outweighs any potential punishment. Even will-

ing to risk jail time for their activities, so-called suicide hackers

are the truly scary monsters in the closet. These guys work in a

scorched-earth mentality and do not care about their own safety

or freedom, not to mention anyone else’s.

EXAM TIP    ECC loves adding more definitions to the mix to

confuse the issue. Here are a few other ones to remember: script

kiddie (unskilled, using other’s scripts and tools), cyberterrorist

(motivated by religious or political beliefs to create fear and

large-scale systems disruption), and state-sponsored hacker (em-

ployed by a government).

Attack Types

Another area for memorization in our stroll through this intro-

duction concerns the various types of attacks a hacker could at-

tempt. Most of these are fairly easy to identify and seem, at

times, fairly silly to even categorize. After all, do you care what

the attack type is called if it works for you? For this exam, EC-

Council broadly defines all these attack types in four categories:

•   Operating system (OS) attacks Generally speaking, these at-

tacks target the common mistake many people make when in-

stalling operating systems—accepting and leaving all the de-

faults. Administrator accounts with no passwords, all ports left

open, and guest accounts (the list could go on forever) are exam-

ples of settings the installer may forget about. Additionally, oper-

ating systems are never released fully secure—they can’t be, if

you ever plan on releasing them within a timeframe of actual

use—so the potential for an old vulnerability in newly installed

operating systems is always a plus for the ethical hacker.

•   Application-level attacks These are attacks on the actual pro-

gramming code and software logic of an application. Although

most people are cognizant of securing their OS and network, it’s

amazing how often they discount the applications running on

their OS and network. Many applications on a network aren’t

tested for vulnerabilities as part of their creation and, as such,

have many vulnerabilities built into them. Applications on a net-

work are a gold mine for most hackers.

•   Shrink-wrap code attacks These attacks take advantage of the

built-in code and scripts most off-the-shelf applications come

with. The old refrain “Why reinvent the wheel?” is often used to

describe this attack type. Why spend time writing code to attack

something when you can buy it already “shrink-wrapped”?

These scripts and code pieces are designed to make installation

and administration easier but can lead to vulnerabilities if not

managed appropriately.

•   Misconfiguration attacks These attacks take advantage of sys-

tems that are, on purpose or by accident, not configured appro-

priately for security. Remember the triangle earlier and the

maxim “As security increases, ease of use and functionality de-

crease”? This type of attack takes advantage of the administrator

who simply wants to make things as easy as possible for the

users. Perhaps to do so, the admin will leave security settings at

the lowest possible level, enable every service, and open all fire-

wall ports. It’s easier for the users but creates another gold mine

for the hacker.

EXAM TIP    Infowar (as ECC loves to call it) is the use of offen-

sive and defensive techniques to create advantage over your ad-

versary. Defining which actions are offensive vs. defensive in na-

ture should be self-explanatory, so if you’re asked, use common

sense and reasoning. For example, a banner on your system

warning those attempting access that you’ll prosecute is defen-

sive in nature, acting as a deterrent.

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 and 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 mis-

sion or event they were on, that they just “felt” the plane or heli-

copter—that they just knew how it was feeling and the best

thing to do to accomplish the goal, sometimes without even

thinking about it.

I was talking to my daughter a while back and asked her

about this human–machine relationship. She paused for a mo-

ment 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 followed a procedure and took their time up front, the

decision making and “feel” of the machine gets to come to

fruition.

Hacking phases, as identified by EC-Council, are a great way to

think about an attack structure for you, my hacking pilot

trainee. I’m not saying you shouldn’t take advantage of opportu-

nities 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), but in general following the plan will produce

quality results. Although there are many different terms for

these phases and some of them run concurrently and continu-

ously throughout a test, EC-Council has defined the standard

hack as having five phases, shown in Figure 1-7. Whether the at-

tacker is ethical or malicious, these five phases capture the full

breadth of the attack.

Figure 1-7 Phases of ethical hacking

EXAM TIP    Keep the phases of hacking in mind throughout

your study. You’ll most likely see several questions asking you to

identify not only what occurs in each step but which tools are

used in each one.

Reconnaissance is probably going to be the most difficult

phase to understand for the exam, mainly because many people

confuse some of its steps as being part of the next phase (scan-

ning and enumeration). Reconnaissance is nothing more than

the steps taken to gather evidence and information on the tar-

gets you want to attack. It can be passive in nature or active.

Passive reconnaissance involves gathering information about

your target without their knowledge, whereas active reconnais-

sance uses tools and techniques that may or may not be discov-

ered but put your activities as a hacker at more risk of discovery.

Another way of thinking about it is from a network perspective:

active is that which purposefully puts packets, or specific com-

munications, on a wire to your target, whereas passive does not.

For example, imagine your penetration test, also known as a

pen test, has just started and you know nothing about the com-

pany you are targeting. Passively, you may simply watch the out-

side of the building for a couple of days to learn employee habits

and see what physical security measures are in place. Actively,

you may simply walk up to the entrance or guard shack and try

to open the door (or gate). In either case, you’re learning valu-

able information, but with passive reconnaissance you aren’t

taking any action to signify to others that you’re watching.

Examples of actions that might be taken during this phase are

social engineering, dumpster diving, and network sniffing—all

of which are addressed throughout the remainder of this exam

study guide.

NOTE    Every pen tester on the planet who’s been knee-deep in

a dumpster with a guard’s flashlight in their face knows that

dumpster diving is about as passive an activity as participating

in a marathon. Just keep in mind that sometimes definitions and

reality don’t match up. For your exam, it’s passive. In real life,

it’s a big risk, and you’ll probably get stinky.

In the second phase, scanning and enumeration, security pro-

fessionals take the information they gathered in recon and ac-

tively apply tools and techniques to gather more in-depth infor-

mation on the targets. This can be something as simple as run-

ning a ping sweep or a network mapper to see what systems are

on the network, or as complex as running a vulnerability scan-

ner to determine which ports may be open on a particular sys-

tem. For example, whereas recon 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.

The third phase, as they say, 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 by-

passing a security control. In the gaining access phase, true at-

tacks are leveled against the targets enumerated in the second

phase. These attacks can be as simple as accessing an open and

nonsecured wireless access point and then 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 study guide.

In the fourth phase, maintaining access, hackers attempt to

ensure they have a way back into the machine or system they’ve

already compromised. Back doors are left open by the attacker

for future use, especially if the system in question has been

turned into a zombie (a machine used to launch further attacks

from) or if the system is used for further information gathering

—for example, a sniffer can be placed on a compromised ma-

chine to watch traffic on a specific subnet. Access can be main-

tained through the use of 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 oftentimes 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 in-

formation 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 done what you want or need to without bothering to es-

calate to root privilege, huzzah!

In the final phase, covering tracks, attackers attempt to con-

ceal their success and avoid detection by security professionals.

Steps taken here consist of removing or altering log files, hiding

files with hidden attributes or directories, and even using tun-

neling protocols to communicate with the system. If auditing is

turned on and monitored, and often it is not, log files are an in-

dicator of 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 an at-

tack is in progress, files get corrupted all the time, and, 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 organiza-

tion but it may also prevent them 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.

EXAM TIP    An acronym you should definitely get acquainted

with is SIEM (which stands for security incident and event man-

agement). 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.

A couple of insights can, and should, be gained here. First,

contrary to popular belief, pen testers do not usually just ran-

domly assault things hoping to find some overlooked vulnerabil-

ity to exploit. Instead, they follow a specific, organized method

to thoroughly discover every aspect of the system they’re target-

ing. 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 in-

clusion in the final report. Mr. Horton, our beloved technical edi-

tor, put it this way: “Pen testers are thorough in their work for

the customer. Hackers just discover what is necessary to accom-

plish their goal.” Second, keep in mind that security profession-

als performing a pen test do not normally repair or patch any se-

curity vulnerabilities they find—it’s simply not their job to do so.

The ethical hacker’s job is to discover security flaws for the cus-

tomer, 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 attack-

ing before enumerating, then so be it.

The Ethical Hacker

So, what makes someone an “ethical” hacker? Can such a thing

even exist? Considering the art of hacking computers and sys-

tems is, in and of itself, a covert action, most people might be-

lieve the thought of engaging in a near-illegal activity to be sig-

nificantly unethical. However, the purpose and intention of the

act have to be taken into account.

For comparison’s sake, law enforcement professionals rou-

tinely 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 behav-

iors 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 vulnerabil-

ities 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.

In CEH parlance, and as defined by several other entities,

there is a distinct difference between a hacker and a cracker. An

ethical hacker is someone who employs the same tools and tech-

niques 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 either for personal gain or 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 either act on their own or, in some

cases, act as hired agents to destroy or damage government or

corporate reputation.

One all-important specific identifying a hacker as ethical ver-

sus the bad-guy crackers needs to be highlighted and repeated

over and over again. Ethical hackers work within the confines of

an agreement made between themselves and a customer before

any action is taken. This agreement isn’t simply a smile, a con-

versation, and a handshake just before you flip open a laptop

and start hacking away. No, instead it is a carefully laid-out plan,

meticulously arranged and documented to protect both you (the

ethical hacker) and the client.

In general, an ethical hacker will first meet with the client and

sign a contract. The contract defines not only the permission and

authorization given to the security professional (sometimes

called a get-out-of-jail-free card) but also confidentiality and

scope. No client would ever agree to having an ethical hacker at-

tempt to breach security without first ensuring the hacker will

not disclose any information found during the test. Usually, this

concern results in the creation of a nondisclosure agreement

(NDA).

Additionally, 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 col-

lection.” They may also want to restrict what types of attacks you

run. For example, the client may be perfectly okay with you at-

tempting a password hack against their systems but may not

want you to test every DoS attack you know.

Oftentimes, however, even though you’re hired to test their

security and you know what’s really important in security and

hacking circles, the most serious risks to a target are not allowed

to be tested because of the “criticality of the resource.” 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 crit-

ical resource in today’s test will become a focus of scrutiny and

“Let’s see what happens” next year. If the test designed to im-

prove security actually blows up a server, it may not be a win-

ning 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 back-end process-

ing 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.

NOTE    A common term you’ll see referenced in your CEH study

is tiger team, which is nothing more than a group of people,

gathered together by a business entity, working to address a spe-

cific problem or goal. Ethical hackers are sometimes part of a

tiger team, set up to thoroughly test all facets of a security sys-

tem. Whether you’re hired as part of the team or as an individ-

ual, pay attention to the rules of engagement.

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 medical facilities need to maintain

compliance with the Health Insurance Portability and

Accountability Act (HIPAA) and will hire ethical hackers to com-

plete their accreditation. Sometimes the organization’s leader-

ship is simply security conscious and wants to know just how

well existing security controls are functioning. And sometimes

it’s simply an effort to rebuild trust and reputation after a secu-

rity 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 cards 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. 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 and has three

major phases. Once the pen test is agreed upon, the ethical

hacker begins the “assault” using a variety of tools, methods, and

techniques, but generally follows the same five stages of a typi-

cal hack to conduct the test. 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 pen test has three main phases—preparation, assessment,

and conclusion—and they are fairly easy to define and under-

stand. 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 per-

form the activity are all agreed upon in this phase. The assess-

ment 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. Lastly, the conclusion (or post-assessment) phase de-

fines the time when final reports are prepared for the customer,

detailing the findings of the tests (including the types of tests

performed) and many times even providing recommendations

to improve security.

In performing a pen test, an ethical hacker must attempt to re-

flect the criminal world as much as possible. In other words, if

the steps taken by the ethical hacker during the pen test don’t

adequately mirror what a “real” hacker would do, then the test

is doomed to failure. For that reason, most pen tests have indi-

viduals acting in various stages of knowledge about the target of

evaluation (TOE). These different types of tests are known by

three names: black box, white box, and gray box.

In black-box testing, the ethical hacker has absolutely no

knowledge of the TOE. The testing is designed to simulate an out-

side, unknown attacker, and it takes the most amount of time to

complete and, usually, is by far the most expensive option. For

the ethical hacker, black-box testing means a thorough romp

through the five stages of an attack and removes any precon-

ceived notions of what to look for. The only true drawback to

this type of test is it focuses solely on the threat outside the orga-

nization and does not take into account any trusted users on the

inside.

NOTE    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 what an exter-

nal hacker has and knows about 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.

White-box testing is the exact opposite of black-box testing. In

this type, pen testers have full knowledge of the network, sys-

tem, and infrastructure they’re targeting. This, quite obviously,

makes the test much quicker, easier, and less expensive, and it 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 knowl-

edge 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 adminis-

tration level, gray-box testing assumes only that the attacker is

an insider. Because most attacks do originate from inside a net-

work, this type of testing is valuable and can demonstrate privi-

lege escalation from a trusted employee.

Laws and Standards

Finally, it would be impossible to call yourself an ethical any-

thing if you didn’t understand the guidelines, standards, and

laws that govern your particular area of expertise. In our realm

of IT security (and in ethical hacking), there are tons of laws and

standards you should be familiar with, not only to do a good job,

but to keep you out of trouble—and prison. We were lucky in

previous versions of the exam that these didn’t get hit very of-

ten, but now they’re back—and with a vengeance.

I would love to promise I could provide you a comprehensive

list of every law you’ll need to know for your job, 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 end-

less. 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 be-

cause 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.

Sometimes You Have to Know Everything

A foundational principle in Western law and order is that igno-

rance of the law does not make one free of it. In other words, if

you break a law, you cannot use the excuse that you didn’t know

about the law in question. On its face this could seem somewhat

unfair. I mean, how in the world am I supposed to know EVERY

law in EVERY state and EVERY setting? The flip side of it, and the

reason it’s a foundational principle, is simply if ignorance were a

valid excuse, any time someone was accused of a law they could

simply claim ignorance and be set free.

So how do we, as a civilized society with rule of law at our

core (supposedly) find the happy balance in this? I like the way

USLegal.com puts it: “Ignorance of law means want of knowl-

edge of those laws which a person has a duty to know and which

everyman is presumed to know.” That last bit is the important

part: you, as a citizen, have a duty to know the law of the land as

it relates to you and yours. Digging a little deeper into that

thought, then, ignorance can be either voluntary or involuntary.

Voluntary is pretty simple to define: if you could have reason-

ably acquired knowledge of the law but you claim you do not

know of it, you’re purposeful in your ignorance. Involuntary is

the area in which there’s a little wiggle room.

For example (again from USLegal.com), “...case law has recog-

nized certain exceptions to the doctrine. For example in Cheek v.

United States, 498 U.S. 192, 200-201 (U.S. 1991) the court ob-

served that the proliferation of statutes and regulations has

sometimes made it difficult for the average citizen to know and

comprehend the extent of the duties and obligations imposed by

the tax laws.” In short, Congress stated that the overly complex

tax law was more than the average citizen could be expected to

know and understand and, therefore, ignorance of certain areas

of tax law has had sentencing/conviction largely reduced.

In criminal law, while ignorance may not clear a defendant of

guilt, it can be a consideration in sentencing—and this next part

is very important here, particularly where the law is unclear or

the defendant sought advice from law enforcement or regula-

tory officials who themselves were unaware of the law or ad-

vised against the law as written. The entirety of the doctrine as-

sumes the law in question has been properly promulgated—that

is, published, distributed, and made readily available to the pub-

lic so that “everyman” can be reasonably expected to know it. In

other words, to quote the Decretum Gratiani (google it), “a secret

law is no law at all.”

So why am I talking about principles of law and order in a

book supposedly about ethical hacking? Because, dear reader,

what we’re doing here can easily land you in a world of trouble if

you make yourself willfully ignorant of the laws as they pertain to

networking, data, and hacking. There’s more than ample legal

precedent that any person taking part in activities or employ-

ment outside what could be considered common for an average

citizen must make themselves aware of any and all applicable

laws. For example, a person running the water supply for a city,

or a nuclear plant, or creating and maintaining bridges people

drive over is required to know the laws necessary to engage in

those activities.

You’re an ethical hacker, meaning (among other things) your

intent is to abide by written law (and customer agreements). But

your intent means squat in a court of law. Read up on the laws

mentioned here in this book. Then go search out updates to

them. Then look for others. After all, if you’re working for a com-

pany in Georgia, performing a pen test on a company in

Wyoming with offshore facilities, which law trumps the others

and how are you supposed to know?

While your company should provide some protection for you,

and is obligated to assist you in learning/knowing the laws you’ll

be held to during any given employment exercise, unfortunately

the answer to that question, at least in the eyes of the law, is you

better figure it out yourself.

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 de-

sign, are provided and shared to doctors, hospitals, and insur-

ance providers. HIPAA has five subsections that are fairly self-

explanatory (Electronic Transaction and Code Sets, Privacy Rule,

Security Rule, National Identifier Requirements, and

Enforcement) and may show up on your exam.

Another important law for your study is the Sarbanes-Oxley

(SOX) Act. SOX was 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 in-

terest and enforcement for accountability.

NOTE    One thing that may help you in setting up better security

is OSSTMM—the Open Source Security Testing Methodology

Manual (if you really want to sound snooty, call it “awstem”). It’s

a peer-reviewed, formalized methodology of security testing and

analysis that can “provide actionable information to measurably

improve your operational security.” It defines three types of

compliance for testing: legislative (government regulations), con-

tractual (industry or group requirements), and standards based

(practices that must be followed in order to remain a member of

a group or organization).

When it comes to standards, again there are tons to know—

maybe not necessarily for your job, but because you’ll see them

on this exam. ECC really wants you to pay attention to PCI-DSS,

COBIT, and ISO/IEC 27001:2013. The Payment Card Industry Data

Security Standard (PCI-DSS) is a security standard for organiza-

tions handling credit cards, ATM cards, and other point-of-sales

cards. The standards apply to all groups and organizations in-

volved in the entirety of the payment process—from card is-

suers, to merchants, to those storing and transmitting card infor-

mation—and consist of 12 requirements:

•   Requirement 1: Install and maintain firewall configuration to

protect data.

•   Requirement 2: Remove vendor-supplied default passwords and

other default security features.

•   Requirement 3: Protect stored data.

•   Requirement 4: Encrypt transmission of cardholder data.

•   Requirement 5: Install, use, and update AV (antivirus).

•   Requirement 6: Develop secure systems and applications.

•   Requirement 7: Use “need to know” as a guideline to restrict ac-

cess to data.

•   Requirement 8: Assign a unique ID to each stakeholder in the

process (with computer access).

•   Requirement 9: Restrict any physical access to the data.

•   Requirement 10: Monitor all access to data and network re-

sources holding, transmitting, or protecting it.

•   Requirement 11: Test security procedures and systems regularly.

•   Requirement 12: Create and maintain an information security

policy.

Control Objects for Information and Related Technology

(COBIT) is another security standard you’ll probably see refer-

enced. Created by the Information Systems Audit and Control

Association (ISACA) and the IT Governance Institute (ITGI),

COBIT is (from ISACA’s own website) “an IT governance frame-

work and supporting toolset that allows managers to bridge the

gap between control requirements, technical issues and business

risks. COBIT enables clear policy development, good practice,

and emphasizes regulatory compliance.” It does so in part by

categorizing control objectives into the following domains:

•   Planning and organization

•   Acquisition and implementation

•   Delivery and support

•   Monitoring and evaluation

Each domain contains specific control objectives. This stan-

dard helps security architects figure out and plan minimum se-

curity requirements for their organizations.

Want more? I don’t either, so I’ll leave you with the last exam-

ple ECC wants you to focus on: the ISO/IEC 27001:2013. It pro-

vides requirements for creating, maintaining, and improving or-

ganizational IS (Information Security) systems. The standard ad-

dresses issues such as ensuring compliance with laws as well as

formulating internal security requirements and objectives.

EXAM TIP    Law is a funny thing, and there are semantic terms

a-plenty regarding it. Be aware of the differences between crimi-

nal law (a body of rules and statutes that defines conduct pro-

hibited by the government because it threatens and harms pub-

lic safety and welfare and that establishes punishment to be im-

posed 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, prop-

erty, 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 Information Security laws are

tricky things when it comes to national borders. While it’s easy

to enforce an American 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 this book or

any other. You will have to spend some time with your employer

and your team to learn what you need before testing anything.

Who’s to Blame?

Oftentimes in crime dramas we don’t get to see the full story.

This is mainly because we’re all focused on the one bad guy—the

one person to blame for it all. But in the digital world, things can

get a little hairy in the blame game. For example, suppose Joe

sends Bob something truly terrible. Maybe they’re dealing in

stolen materials or sending child porn to one another. Obviously

Joe and Bob are at fault and need to face some justice. But what

about their ISPs? What about those entities that make all that il-

legal back and forth even possible in the first place? If Joe sends

Bob child porn over AT&T’s network, for example, why is AT&T

(or the countless other ISPs and/or networks between the two)

not liable for facilitating the transaction? If Sally sends a piece of

malware and takes out Jane’s network, would it have occurred

without countless networks between them? How and why are

they not liable?

In general, and without turning this into a legal paper, the

real answer is we don’t want them to be. And that is a very good

thing. For example, if Joe sends Bob printed photos in a sealed

overnight container, should the FedEx guy driving the truck be

held liable if those photos are illegal in nature? If Sally mails a

bag of drugs to Jane, is the postal worker delivering the package

at fault? Of course not, and barring gross negligence, the same

protections and thought process should apply to networks.

ISPs are basically just dumb pipes we use to blast information

to each other. The faster we blast said information, the happier

we all are. Don’t believe me? Go somewhere streaming gets

overcrowded and listen to how people rant about the latest cat

video lagging on their system. I’m not saying ISP’s can, or do, just

bask in the sun regardless of the traffic they’re carrying: most if

not all take active measures to restrict and reduce illegal activity

on the networks, and they do hold some responsibility insofar as

gross negligence is concerned. But generally speaking, they are

in the business of making sure data moves quickly from point A

to point B. And it’s safer that they stay as such.

In the Summer of 2015, the FCC classified Internet service

providers as common carriers. While heretofore defined as com-

panies that transport goods or people for any person or com-

pany (and bearing responsibility in part for any possible loss of

the goods during transport), the use here was different: ISPs

transport data, not goods or people. In the original sense, com-

mon carriers were responsible for loss or damage except for cer-

tain circumstances—like an Act of God, fault or fraud on the part

of the shipper, or defects in the goods themselves. When it came

to telecommunications, though, those stipulations didn’t apply in

the same way. Therefore, innumerable stipulations and laws es-

tablished some cover for providers: for example, the

Communications Decency Act protected against third-party con-

tent on grounds of libel or slander, and DMCA “safe harbors”

provided more liability protection in regards to copyright in-

fringements. Not to mention all of it continues to tie into net

neutrality and the back and forth we’ve seen on that for the past

decade.

So who should be held liable for malicious or illegal traffic?

Sure a purposeful sender and knowing recipient should be. But

everyone else along the way? Not as clear to see—especially

when the cat video won’t load.

NOTE    Don’t forget one very simple, obvious observation some

people just don’t think about: the Internet is global. The differ-

ence 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, many may

see it as malicious if it just transits your system.

Chapter Review

Tips that will help on your exam include:

•   Do not let real life trump EC-Council’s view of it. Real life and the

certification exam do not necessarily always directly

correspond.

•   Use time to your advantage. The exam now is split into sections,

with a timeframe set up for each one. You can work and review

inside the section all you want, but once you pass through it, you

can’t go back.

•   Make use of the paper and pencil/pen the friendly test proctor

provides you, and as soon as you sit down, before you click

START, start writing down everything you can remember onto

the paper provided.

•   Trust your instincts. When you do question review, unless you

absolutely, positively, beyond any shadow of a doubt know you

initially marked the wrong answer, do not change it.

•   Take the questions at face value. Don’t read into them; just an-

swer them and move on.

The five zones ECC has defined are Internet (outside the

boundary and uncontrolled), Internet DMZ (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), Intranet

Zone (controlled zone that has little to no heavy restrictions),

and Management Network Zone (highly secured zone with very

strict policies).

To be a successful ethical hacker, you don’t need the knowl-

edge of just tools and techniques but also the background infor-

mation that provides a secure foundation for your career. This

all begins with basic networking knowledge, including the seven

layers of the OSI reference model (Application, Presentation,

Session, Transport, Network, Data Link, and Physical) and the

four layers of the TCP/IP stack (Application, Transport, Internet,

and Network Access). Key points include the protocol data unit

(PDU) at each layer (which includes data, segment, packet,

frame, and bit), the makeup of an Ethernet frame, and the TCP

three-way handshake (SYN, SYN/ACK, ACK).

There are innumerable security concepts and terms essential

to your success on the exam, and they can’t possibly all be listed

here. A few examples include the Security, Functionality, and

Usability triangle, hack value, vulnerability, zero-day attack, pay-

load, exploit, daisy-chaining, bots, doxing, and incident response

team (IRT). Memorization is the only option for these terms.

Risk management includes identifying organizational assets,

threats to those assets, and asset vulnerabilities, allowing the

company to explore which countermeasures security personnel

could put into place to minimize risks as much as possible. These

security controls would then greatly increase the security pos-

ture of the systems. Controls can be preventative, detective, or

corrective. A business impact analysis (BIA) is an effort to iden-

tify the systems and processes that are critical for operations.

This includes measurements of the maximum tolerable down-

time (MTD), which provides a means to prioritize the recovery of

assets should the worst occur. A set of plans and procedures to

follow in the event of a failure or a disaster to get business ser-

vices back up and running is called the business continuity plan

(BCP), which includes a disaster recovery plan (DRP), addressing

exactly what to do to recover any lost data or services.

The ALE (annualized loss expectancy) is the product of the

ARO (annual rate of occurrence) and the SLE (single loss ex-

pectancy). The exposure factor (EF) is used to generate the SLE

(EF × Value of Asset).

Another bedrock of security is the security triad of confiden-

tiality, integrity, and availability. Confidentiality, or addressing

the secrecy and privacy of information, refers to the measures

taken to prevent the disclosure of information or data to unau-

thorized individuals or systems. The use of passwords is by far

the most common logical measure taken to ensure confidential-

ity, and attacks against passwords are the most common confi-

dentiality attacks. Integrity refers to the methods and actions

taken to protect the information from unauthorized alteration

or revision—whether the data is at rest or in transit. Integrity in

information systems is often ensured through the use of a hash

(a one-way mathematical algorithm such as MD5 or SHA-1).

Availability refers to the communications systems and data be-

ing ready for use when legitimate users need it. Denial-of-ser-

vice (DoS) attacks are designed to prevent legitimate users from

having access to a computer resource or service and can take

many forms.

Security policies represent the administrative function of se-

curity and attempt to describe the security controls imple-

mented in a business to accomplish a goal (defining exactly what

your business believes is the best way to secure its resources).

There are many types of security policies addressing a variety of

specific issues within the organization. Some examples are

Information Security Policy, Password Policy, Information

Protection Policy, Remote Access Policy, and Firewall

Management Policy.

Defining an ethical hacker, as opposed to a cracker (or mali-

cious hacker), basically comes down to the guidelines one works

under—an ethical hacker works only with explicit consent and

approval from a customer. Ethical hackers are employed by cus-

tomers to improve security. Crackers either act on their own or,

in some cases, are employed by malicious entities to destroy or

damage government or corporate reputation. In addition, some

hackers who use their knowledge to promote a political cause

are referred to as hacktivists.

Hackers are generally classified into three separate groups.

White hats are the ethical hackers hired by a customer for the

specific goal of testing and improving security or for other de-

fensive purposes. Black hats are the crackers illegally using their

skills either for personal gain or for malicious intent, and they

do not ask for permission or consent. Gray hats are neither good

nor bad; they are simply curious about hacking tools and tech-

niques or feel like it’s their duty, with or without customer per-

mission, to demonstrate security flaws in systems. In any case,

hacking without a customer’s explicit permission and direction

is a crime. Other terms include suicide and state-sponsored

hackers, cyberterrorists, and script kiddies.

A penetration test, also known as a pen test, is a clearly de-

fined, full-scale test of the security controls of a system or net-

work in order to identify security risks and vulnerabilities. The

three main phases in a pen test are preparation, assessment, and

conclusion. The preparation phase defines the time period when

the actual contract is hammered out. The scope of the test, the

types of attacks allowed, and the individuals assigned to per-

form the activity are all agreed upon in this phase. The assess-

ment phase (sometimes also known as the security evaluation

phase or the conduct phase) is when the actual assaults on the

security controls are conducted. The conclusion (or post-assess-

ment) phase defines the time when final reports are prepared

for the customer, detailing the findings of the test (including the

types of tests performed) and many times even providing recom-

mendations to improve security.

The act of hacking consists of five main phases.

Reconnaissance involves the steps taken to gather evidence and

information on the targets you want to attack. It can be passive

in nature or active. The scanning and enumeration phase takes

the information gathered in recon and actively applies tools and

techniques to gather more in-depth information on the targets.

In the gaining access phase, true attacks are leveled against the

targets enumerated in the second phase. In the fourth phase,

maintaining access, hackers attempt to ensure they have a way

back into the machine or system they’ve already compromised.

Finally, in the final phase, covering tracks, attackers attempt to

conceal their success and avoid detection by security

professionals.

Three types of tests are performed by ethical hackers. In

black-box testing, the ethical hacker has absolutely no knowl-

edge of the target of evaluation (TOE). It’s designed to simulate

an outside, unknown attacker. In white-box testing, pen testers

have full knowledge of the network, system, and infrastructure

they are testing, and it is designed to simulate a knowledgeable

internal threat, such as a disgruntled network admin or other

trusted user. In gray-box testing, the attacker has limited knowl-

edge about the TOE. It is designed to simulate privilege escala-

tion from a trusted employee.

The guidelines, standards, and laws that govern ethical hack-

ing are important. These include FISMA, Electronics

Communications Privacy Act, PATRIOT Act, Privacy Act of 1974,

Cyber Intelligence Sharing and Protection Act (CISPA), Consumer

Data Security and Notification Act, and Computer Security Act of

1987.

The Health Insurance Portability and Accountability Act

(HIPAA) was 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 de-

sign, are provided and shared to doctors, hospitals, and insur-

ance providers. HIPAA has five subsections that are fairly self-

explanatory (Electronic Transaction and Code Sets, Privacy Rule,

Security Rule, National Identifier Requirements, and

Enforcement) and may show up on your exam.

The Sarbanes-Oxley (SOX) Act was 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.

The Payment Card Industry Data Security Standard (PCI-DSS)

is 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 stor-

ing and transmitting card information—and consist of 12

requirements:

•   Requirement 1: Install and maintain firewall configuration to

protect data.

•   Requirement 2: Remove vendor-supplied default passwords and

other default security features.

•   Requirement 3: Protect stored data.

•   Requirement 4: Encrypt transmission of cardholder data.

•   Requirement 5: Install, use, and update AV (antivirus).

•   Requirement 6: Develop secure systems and applications.

•   Requirement 7: Use “need to know” as a guideline to restrict ac-

cess to data.

•   Requirement 8: Assign a unique ID to each stakeholder in the

process (with computer access).

•   Requirement 9: Restrict any physical access to the data.

•   Requirement 10: Monitor all access to data and network re-

sources holding, transmitting, or protecting it.

•   Requirement 11: Test security procedures and systems regularly.

•   Requirement 12: Create and maintain an information security

policy.

Control Objects for Information and Related Technology

(COBIT) was created by the Information Systems Audit and

Control Association (ISACA) and the IT Governance Institute

(ITGI). It categorizes control objectives into the following

domains:

•   Planning and organization

•   Acquisition and implementation

•   Delivery and support

•   Monitoring and evaluation

Each domain contains specific control objectives. This stan-

dard helps security architects figure out and plan minimum se-

curity requirements for their organizations.

Lastly, ISO/IEC 27001:2013 provides requirements for creating,

maintaining, and improving organizational IS (Information

Security) systems. The standard addresses issues such as ensur-

ing compliance with laws as well as formulating internal secu-

rity requirements and objectives.

Questions

1.   Which of the following would be the best example of a deterrent

control?

A.   A log aggregation system

B.   Hidden cameras onsite

C.   A guard posted outside the door

D.   Backup recovery systems

2.   Enacted in 2002, this U.S. law requires every federal agency to

implement information security programs, including significant

reporting on compliance and accreditation. Which of the follow-

ing is the best choice for this definition?

A.   FISMA

B.   HIPAA

C.   NIST 800-53

D.   OSSTMM

3.   Brad has done some research and determined a certain set of

systems on his network fail once every ten years. The purchase

price for each of these systems is $1200. Additionally, Brad dis-

covers the administrators on staff, who earn $50 an hour, esti-

mate five hours to replace a machine. Five employees, earning

$25 an hour, depend on each system and will be completely un-

productive while it is down. If you were to ask Brad for an ALE

on these devices, what should he answer with?

A.   $2075

B.   $207.50

C.   $120

D.   $1200

4.   An ethical hacker is hired to test the security of a business net-

work. The CEH is given no prior knowledge of the network and

has a specific framework in which to work, defining boundaries,

nondisclosure agreements, and the completion date. Which of

the following is a true statement?

A.   A white hat is attempting a black-box test.

B.   A white hat is attempting a white-box test.

C.   A black hat is attempting a black-box test.

D.   A black hat is attempting a gray-box test.

5.   When an attack by a hacker is politically motivated, the hacker

is said to be participating in which of the following?

A.   Black-hat hacking

B.   Gray-box attacks

C.   Gray-hat attacks

D.   Hacktivism

6.   Two hackers attempt to crack a company’s network resource se-

curity. One is considered an ethical hacker, whereas the other is

not. What distinguishes the ethical hacker from the “cracker”?

A.   The cracker always attempts white-box testing.

B.   The ethical hacker always attempts black-box testing.

C.   The cracker posts results to the Internet.

D.   The ethical hacker always obtains written permission before

testing.

7.   In which stage of an ethical hack would the attacker actively ap-

ply tools and techniques to gather more in-depth information on

the targets?

A.   Active reconnaissance

B.   Scanning and enumeration

C.   Gaining access

D.   Passive reconnaissance

8.   Which type of attack is generally conducted as an inside at-

tacker with elevated privileges on the resources?

A.   Gray box

B.   White box

C.   Black box

D.   Active reconnaissance

9.   Which of the following Common Criteria processes refers to the

system or product being tested?

A.   ST

B.   PP

C.   EAL

D.   TOE

10.   Your company has a document that spells out exactly what em-

ployees are allowed to do on their computer systems. It also de-

fines what is prohibited and what consequences await those

who break the rules. A copy of this document is signed by all em-

ployees prior to their network access. Which of the following

best describes this policy?

A.   Information Security Policy

B.   Special Access Policy

C.   Information Audit Policy

D.   Network Connection Policy

11.   Sally is a member of a pen test team newly hired to test a bank’s

security. She begins searching for IP addresses the bank may

own by searching public records on the Internet. She also looks

up news articles and job postings to discover information that

may be valuable. In what phase of the pen test is Sally working?

A.   Preparation

B.   Assessment

C.   Conclusion

D.   Reconnaissance

12.   Joe is a security engineer for a firm. His company downsizes,

and Joe discovers he will be laid off within a short amount of

time. Joe plants viruses and sets about destroying data and set-

tings throughout the network, with no regard to being caught.

Which type of hacker is Joe considered to be?

A.   Hacktivist

B.   Suicide hacker

C.   Black hat

D.   Script kiddie

13.   Elements of security include confidentiality, integrity, and avail-

ability. Which technique provides for integrity?

A.   Encryption

B.   UPS

C.   Hashing

D.   Passwords

14.   Which of the following best describes an effort to identify sys-

tems that are critical for continuation of operation for the

organization?

A.   BCP

B.   BIA

C.   MTD

D.   DRP

Answers

1.   C. If you’re doing something as a deterrent, you’re trying to pre-

vent an attack in the first place. In this physical security deter-

rent control, a guard visible outside the door could help prevent

physical attacks.

2.   A. FISMA has been around since 2002 and was updated in 2014.

It gave certain information security responsibilities to NIST,

OMB, and other government agencies, and declared the

Department of Homeland Security (DHS) as the operational lead

for budgets and guidelines on security matters.

3.   B. ALE = ARO × SLE. To determine ARO, divide the number of oc-

currences by the number of years (1 occurrence / 10 years = 0.1).

To determine SLE, add the purchase cost (1200) plus the amount

of time to replace (5 × 50 = 250) plus the amount of lost work (5

hours × 5 employees × 25 = 625). In this case, it all adds up to

$2075. ALE = 0.1 × 2075, or $207.50.

4.   A. In this example, an ethical hacker was hired under a specific

agreement, making him a white hat. The test he was hired to

perform is a no-knowledge attack, making it a black-box test.

5.   D. Hackers who use their skills and talents to forward a cause or

a political agenda are practicing hacktivism.

6.   D. The ethical hacker always obtains written permission before

testing and never performs a test without it!

7.   B. The second of the five phases of an ethical hack attempt, scan-

ning and enumeration, is the step where ethical hackers take the

information they gathered in recon and actively apply tools and

techniques to gather more in-depth information on the targets.

8.   B. A white-box attack is intended to simulate an internal at-

tacker with elevated privileges, such as a network administrator.

9.   D. The target of evaluation (TOE) is the system or product being

tested.

10.   A. The Information Security Policy defines what is allowed and

not allowed, and what the consequences are for misbehavior in

regard to resources on the corporate network. Generally this is

signed by employees prior to their account creation.

11.   B. The assessment phase, which EC-Council also likes to inter-

changeably denote as the “conduct” phase sometimes, is where

all the activity takes place—including the passive information

gathering performed by Sally in this example.

12.   B. A suicide hacker doesn’t care about being caught. Jail time

and punishment mean nothing to these guys. While sometimes

they are tied to a political or religious group or function, some-

times they’re just angry folks looking to make an entity pay for

some perceived wrongdoing.

13.   C. A hash is a unique numerical string, created by a hashing al-

gorithm on a given piece of data, used to verify data integrity.

Generally, hashes are used to verify the integrity of files after

download (comparison to the hash value on the site before

download) and/or to store password values. Hashes are created

by a one-way algorithm.

14.   B. The business impact analysis best matches this description.

Although maximum tolerable downtime is part of the process,

and a continuity plan certainly addresses it, a BIA is the actual

process to identify those critical systems.

Support Sign Out

©2022 O'REILLY MEDIA, INC.  TERMS OF SERVICE PRIVACY POLICY